#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d678a59d |
|
18-May-2024 |
Tom Rini <trini@konsulko.com> |
Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"" When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
e51478ba |
|
27-Apr-2024 |
Tom Rini <trini@konsulko.com> |
x86: Remove <common.h> and add needed includes Remove <common.h> from all x86 architecture files and when needed add missing include files directly. Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ffff21fb |
|
05-Feb-2023 |
Simon Glass <sjg@chromium.org> |
x86: Correct Chrromebook typo Fix a typo in a comment. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
02541601 |
|
02-Aug-2021 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Don't program MTRR for DRAM for FSP1 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
401d1c4f |
|
30-Oct-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop asm/global_data.h from common header 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
d46c0932 |
|
04-Nov-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Adjust calculations for MTRR range and DRAM top 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
70c202c4 |
|
22-Sep-2020 |
Simon Glass <sjg@chromium.org> |
x86: Add a way to add to the e820 memory table 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
4f0c4be1 |
|
28-Jul-2020 |
Heinrich Schuchardt <xypron.glpk@gmx.de> |
x86: rename CONFIG_STACK_SIZE 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
ef5f5f6c |
|
09-Jul-2020 |
Simon Glass <sjg@chromium.org> |
x86: Avoid #ifdef with CONFIG_HAVE_ACPI_RESUME 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c793dbdb |
|
26-Apr-2020 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Allow skipping init code when chain loading 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
42791100 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set up the MTRR for SDRAM 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>
|
#
ea4e97a5 |
|
06-Dec-2019 |
Simon Glass <sjg@chromium.org> |
x86: Set the DRAM banks to reflect real location 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
67c4e9f8 |
|
14-Nov-2019 |
Simon Glass <sjg@chromium.org> |
common: Move board_get_usable_ram_top() out of common.h 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
c3863ead |
|
25-Sep-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Save usable RAM and hob_list in the handoff area 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>
|
#
e9de4a7c |
|
24-Aug-2019 |
Simon Glass <sjg@chromium.org> |
x86: fsp: Move common dram functions into a common file 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>
|
#
83d290c5 |
|
06-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert all of our single license tags to Linux Kernel style 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>
|
#
45519924 |
|
11-Apr-2018 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Rename e820entry to e820_entry 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>
|
#
87af71c2 |
|
11-Apr-2018 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Use 'unsigned int' in install_e820_map() functions 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>
|
#
7d0d2efe |
|
21-Apr-2017 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3 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>
|
#
76b00aca |
|
31-Mar-2017 |
Simon Glass <sjg@chromium.org> |
board_f: Drop setup_dram_config() wrapper 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>
|
#
ff1e18af |
|
11-Oct-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Pass mrc cache to fsp_init() and save it to gd after fsp_init() 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>
|
#
196193a4 |
|
28-Sep-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: fsp: Report correct number of E820 table entries 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>
|
#
1ed6648b |
|
22-Jul-2015 |
Bin Meng <bmeng.cn@gmail.com> |
x86: Reserve PCIe ECAM address range in the E820 table 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>
|
#
7b02bf3c |
|
27-Jan-2015 |
Simon Glass <sjg@chromium.org> |
x86: Make CAR and DRAM FSP code common 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>
|