GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/soc/intel/baytrail/Kconfig

245 lines
6.3 KiB
Text
Raw Normal View History

baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
config SOC_INTEL_BAYTRAIL
bool
help
Bay Trail M/D part support.
if SOC_INTEL_BAYTRAIL
config CPU_SPECIFIC_OPTIONS
def_bool y
Introduce stage-specific architecture for coreboot Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-04-23 19:18:48 +02:00
select ARCH_BOOTBLOCK_X86_32
select ARCH_ROMSTAGE_X86_32
select ARCH_RAMSTAGE_X86_32
baytrail/rambi: S3 support and other updates baytrail: Change all GPIO related pull resistors from 10K to 20K Reviewed-on: https://chromium-review.googlesource.com/187570 (cherry picked from commit 762e99861dd1ae61ddcf1ebdec8e698ede54405e) baytrail: workaround kernel using serial console on resume Reviewed-on: https://chromium-review.googlesource.com/188011 (cherry picked from commit b0da3bdb5b6b417ad6cab0084359d4eae1cb4469) baytrail: allow dirty cache line evictions for SMRAM to stick Reviewed-on: https://chromium-review.googlesource.com/188015 (cherry picked from commit 50fb1e6a844e1db05574c92625da23777ad7a0ca) baytrail: Optionally pull up TDO and TMS to avoid power loss in S3. Reviewed-on: https://chromium-review.googlesource.com/188260 (cherry picked from commit e240856609b4eed5ed44ec4e021ed385965768d6) rambi: always load option rom Reviewed-on: https://chromium-review.googlesource.com/188721 (cherry picked from commit d8a1d108548d20755f8683497c215e76d513b7a9) baytrail: use new chromeos ram oops API Reviewed-on: https://chromium-review.googlesource.com/186394 (cherry picked from commit f38e6969df9b5453b10d49be60b5d033d38b4594) rambi: always show dev/rec screens on eDP connected panel Reviewed-on: https://chromium-review.googlesource.com/188731 (cherry picked from commit 7d8570ac52f68492a2250fa536d55f7cbbd9ef95) baytrail: stop e820 reserving default SMM region Reviewed-on: https://chromium-review.googlesource.com/189084 (cherry picked from commit 6fce823512f5db5a09a9c89048334c3524c69a24) baytrai: update MRC wrapper header Reviewed-on: https://chromium-review.googlesource.com/189196 (cherry picked from commit 36b33a25b6603b6a74990b00d981226440b68970) rambi: Put LPE device into ACPI mode Reviewed-on: https://chromium-review.googlesource.com/189371 (cherry picked from commit 5955350cd57fd1b3732b6db62911d824712a5413) baytrail: DPTF: Enable mainboard-specific PPCC Reviewed-on: https://chromium-review.googlesource.com/189576 (cherry picked from commit 27fae3e670244b529b7c0241742fc2b55d52c612) baytrail: Add config option for PCIe wake Reviewed-on: https://chromium-review.googlesource.com/189994 (cherry picked from commit 1cc31a7c021ec84311f1d4e89dd3e57ca8801ab5) rambi: Enable PCIe wake Reviewed-on: https://chromium-review.googlesource.com/189995 (cherry picked from commit c98ae1fee54cfb2b3d3c21a19cdbbf56a0bfa1e6) Squashed 13 commits for baytrail/rambi. Change-Id: I153ef5a43e2bede05cfd624f53e24a0013fd8fb4 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6957 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-02-22 21:26:55 +01:00
select BACKUP_DEFAULT_SMM_REGION
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select CACHE_MRC_SETTINGS
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
select CAR_MIGRATION
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select COLLECT_TIMESTAMPS
baytrail: use CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED On baytrail, it appears that the turbo disable setting is actually building-block scoped. One can see this on quad core parts where if enable_turbo() is called only on the BSP then only cpus 0 and 1 have turbo enabled. Fix this by calling enable_turbo() on all non-bsp cpus. BUG=chrome-os-partner:25014 BRANCH=baytrail TEST=Built and booted rambi. All cpus have bit 38 set to 0 in msr 0x1a0. Change-Id: Id493e070c4a70bb236cdbd540d2321731a99aec2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/182406 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/5048 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-01-15 00:34:10 +01:00
select CPU_INTEL_TURBO_NOT_PACKAGE_SCOPED
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select CPU_MICROCODE_IN_CBFS
select DYNAMIC_CBMEM
baytrail: enable monotonic timer Enabling the monotonic timer allows for collecting boot stage times as well as each device initialization time. BUG=chrome-os-partner:23166 BRANCH=None TEST=Built and booted. Noted timings in console output. Change-Id: I5fdc703ea21710fd26de352f367c6fc0c767ab6a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174422 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4894 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-24 15:42:10 +02:00
select HAVE_MONOTONIC_TIMER
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select HAVE_SMI_HANDLER
baytrail: add reset support Bay Trail has the following types of resets it supports: - Soft reset (INIT# to cpu) - write 0x1 to I/O 0x92 - Soft reset (INIT# to cpu)- write 0x4 to I/0 0xcf9 - Cold reset (S0->S5->S0) - write 0xe to I/0 0xcf9 - Warm reset (PMC_PLTRST# assertion) - write 0x6 to I/O 0xcf9 - Global reset (S0->S5->S0 with TXE reset) - write 0x6 or 0xe to 0xcf9 but with ETR[20] set. While these are documented this support currently provides support for 2nd soft reset as well as cold and warm reset. BUG=chrome-os-partner:23249 BRANCH=None TEST=Built and booted. Change-Id: I9746e7c8aed0ffc29e7afa137798e38c5da9c888 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172710 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/4878 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-10-11 03:54:57 +02:00
select HAVE_HARD_RESET
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
select MMCONF_SUPPORT
select MMCONF_SUPPORT_DEFAULT
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select RELOCATABLE_MODULES
haswell baytrail: Enable RELOCATABLE_RAMSTAGE Change-Id: I84ee953196ae9bed3392c2b9bab2e8d9f0d27908 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7095 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-10-16 13:54:03 +02:00
select RELOCATABLE_RAMSTAGE
baytrail: bring up APs Bring up the APs using x86 MP infrastructure. BUG=chrome-os-partner:22862 BRANCH=None TEST=Built and booted rambi. Noted all cores are brought up. Change-Id: I9231eff5494444e8eb17ecdc5a0af72a2e5208b5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/173704 Reviewed-on: http://review.coreboot.org/4889 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-10-21 19:36:17 +02:00
select PARALLEL_MP
baytrail: Enable PCIe common clock and ASPM Enable the config options to have the device enumeration layer configure common clock and ASPM for endpoints. BUG=chrome-os-partner:23629 BRANCH=baytrail TEST=build and boot on rambi, check PCIe for ASPM and common clock: lspci -vv -s 0:1c.0 | grep LnkCtl: LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ lspci -vv -s 1:00.0 | grep LnkCtl: LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ Change-Id: I2477e3cada0732dc71db0d6692ff5b6159ed269f Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/182860 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5051 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-01-16 20:18:36 +01:00
select PCIEXP_ASPM
select PCIEXP_COMMON_CLOCK
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select SMM_MODULES
select SMM_TSEG
select SMP
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
select SPI_FLASH
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select SSE2
select SUPPORT_CPU_UCODE_IN_CBFS
select TSC_CONSTANT_RATE
baytrail: enable monotonic timer Enabling the monotonic timer allows for collecting boot stage times as well as each device initialization time. BUG=chrome-os-partner:23166 BRANCH=None TEST=Built and booted. Noted timings in console output. Change-Id: I5fdc703ea21710fd26de352f367c6fc0c767ab6a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174422 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4894 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-24 15:42:10 +02:00
select TSC_MONOTONIC_TIMER
baytrail: Rearrange config options alphanumerically This is a no-op change for easier maintenance. BUG=none TEST=manual . baitrail coreboot still builds and runs Change-Id: I0c0bd78c6f361e8f81979f19cce148e7f51865ee Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/171002 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4857 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-28 01:21:04 +02:00
select TSC_SYNC_MFENCE
select UDELAY_TSC
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
config BOOTBLOCK_CPU_INIT
string
default "soc/intel/baytrail/bootblock/bootblock.c"
config MMCONF_BASE_ADDRESS
hex
default 0xe0000000
config MAX_CPUS
int
default 4
config CPU_ADDR_BITS
int
default 36
config SMM_TSEG_SIZE
hex
default 0x800000
config SMM_RESERVED_SIZE
hex
default 0x100000
config HAVE_MRC
bool "Add a Memory Reference Code binary"
default y
help
Select this option to add a blob containing
memory reference code.
Note: Without this binary coreboot will not work
if HAVE_MRC
config MRC_FILE
string "Intel memory refeference code path and filename"
default "3rdparty/northbridge/intel/sandybridge/systemagent-r6.bin"
help
The path and filename of the file to use as System Agent
binary. Note that this points to the sandybridge binary file
which is will not work, but it serves its purpose to do builds.
config MRC_BIN_ADDRESS
hex
default 0xfffa0000
baytrail: romstage: Add config option to enable RMT Add config option to enable RMT in the MRC. BUG=chrome-os-partner:21807 TEST=Manual. Build w/ "USE=rmt", verify RMT print seen on FW console. Build w/o USE flag, verify no RMT print. BRANCH=None. CQ-DEPEND=CL:*148655 Change-Id: Ibd3da87317a3359e797d9b43bc437e7227a85048 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/178095 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4982 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-11-27 00:37:43 +01:00
config MRC_RMT
bool "Enable MRC RMT training + debug prints"
default n
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
endif # HAVE_MRC
# Cache As RAM region layout:
#
# +-------------+ DCACHE_RAM_BASE + DCACHE_RAM_SIZE + DCACHE_RAM_MRC_VAR_SIZE
# | MRC usage |
# | |
# +-------------+ DCACHE_RAM_BASE + DCACHE_RAM_SIZE
# | Stack |\
# | | | * DCACHE_RAM_ROMSTAGE_STACK_SIZE
# | v |/
# +-------------+
# | ^ |
# | | |
# | CAR Globals |
# +-------------+ DCACHE_RAM_BASE
#
# Note that the MRC binary is linked to assume the region marked as "MRC usage"
# starts at DCACHE_RAM_BASE + DCACHE_RAM_SIZE. If those values change then
# a new MRC binary needs to be produced with the updated start and size
# information.
config DCACHE_RAM_BASE
hex
baytrail: adjust cache policy during romstage The caching policy for romstage was previously using a 32KiB of cache-as-ram for both the MRC wrapper and the romstage stack/data. It also used a 32KiB code cache region. The BWG's limitations for the code and data region before memory is up was wrong. It consists of a 16-way set associative 1MiB cache. As long as enough addresses are not read there isn't a risk of evicting the data/stack. Now create a 64KiB cache-as-ram region split evenly between romstage and the MRC wrapper. Additionally cache the memory just below 4GiB in CBFS size. This will cover any code and read-only data needed. BUG=chrome-os-partner:22858 BRANCH=None TEST=Built and booted quickly with corresponding changes to MRC warpper. CQ-DEPEND=CL:*146175 Change-Id: I021cecb886a9c0622005edc389136d22905d4520 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172150 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4868 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-07 23:24:44 +02:00
default 0xff800000
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
config DCACHE_RAM_SIZE
hex
baytrail: adjust cache policy during romstage The caching policy for romstage was previously using a 32KiB of cache-as-ram for both the MRC wrapper and the romstage stack/data. It also used a 32KiB code cache region. The BWG's limitations for the code and data region before memory is up was wrong. It consists of a 16-way set associative 1MiB cache. As long as enough addresses are not read there isn't a risk of evicting the data/stack. Now create a 64KiB cache-as-ram region split evenly between romstage and the MRC wrapper. Additionally cache the memory just below 4GiB in CBFS size. This will cover any code and read-only data needed. BUG=chrome-os-partner:22858 BRANCH=None TEST=Built and booted quickly with corresponding changes to MRC warpper. CQ-DEPEND=CL:*146175 Change-Id: I021cecb886a9c0622005edc389136d22905d4520 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172150 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4868 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-07 23:24:44 +02:00
default 0x8000
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
help
The size of the cache-as-ram region required during bootblock
and/or romstage. Note DCACHE_RAM_SIZE and DCACHE_RAM_MRC_VAR_SIZE
must add up to a power of 2.
config DCACHE_RAM_MRC_VAR_SIZE
hex
baytrail: adjust cache policy during romstage The caching policy for romstage was previously using a 32KiB of cache-as-ram for both the MRC wrapper and the romstage stack/data. It also used a 32KiB code cache region. The BWG's limitations for the code and data region before memory is up was wrong. It consists of a 16-way set associative 1MiB cache. As long as enough addresses are not read there isn't a risk of evicting the data/stack. Now create a 64KiB cache-as-ram region split evenly between romstage and the MRC wrapper. Additionally cache the memory just below 4GiB in CBFS size. This will cover any code and read-only data needed. BUG=chrome-os-partner:22858 BRANCH=None TEST=Built and booted quickly with corresponding changes to MRC warpper. CQ-DEPEND=CL:*146175 Change-Id: I021cecb886a9c0622005edc389136d22905d4520 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172150 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4868 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-10-07 23:24:44 +02:00
default 0x8000
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
help
The amount of cache-as-ram region required by the reference code.
config DCACHE_RAM_ROMSTAGE_STACK_SIZE
hex
default 0x800
help
The amount of anticipated stack usage from the data cache
src/.../Kconfig: various small fixes to texts Fixed spelling and added empty lines to separate the help from the text automatically added during make menuconfig. Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7 Signed-off-by: Daniele Forsi <dforsi@gmail.com> Reviewed-on: http://review.coreboot.org/6313 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-22 18:00:56 +02:00
during pre-RAM ROM stage execution.
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
config RESET_ON_INVALID_RAMSTAGE_CACHE
bool "Reset the system on S3 wake when ramstage cache invalid."
default n
depends on RELOCATABLE_RAMSTAGE
help
The baytrail romstage code caches the loaded ramstage program
in SMM space. On S3 wake the romstage will copy over a fresh
ramstage that was cached in the SMM space. This option determines
the action to take when the ramstage cache is invalid. If selected
the system will reset otherwise the ramstage will be reloaded from
cbfs.
config CBFS_SIZE
hex "Size of CBFS filesystem in ROM"
default 0x100000
help
On Bay Trail systems the firmware image has to store a lot more
than just coreboot, including:
- a firmware descriptor
- Intel Management Engine firmware
- MRC cache information
This option allows to limit the size of the CBFS portion in the
firmware image.
config ENABLE_BUILTIN_COM1
bool "Enable builtin COM1 Serial Port"
default n
help
The PMC has a legacy COM1 serial port. Choose this option to
configure the pads and enable it. This serial port can be used for
the debug console.
config HAVE_ME_BIN
bool "Add Intel Management Engine firmware"
default y
help
The Intel processor in the selected system requires a special firmware
for an integrated controller called Management Engine (ME). The ME
firmware might be provided in coreboot's 3rdparty repository. If
not and if you don't have the firmware elsewhere, you can still
build coreboot without it. In this case however, you'll have to make
sure that you don't overwrite your ME firmware on your flash ROM.
config ME_BIN_PATH
string "Path to management engine firmware"
depends on HAVE_ME_BIN
default "3rdparty/mainboard/$(MAINBOARDDIR)/me.bin"
config HAVE_IFD_BIN
bool
default y
config BUILD_WITH_FAKE_IFD
bool "Build with a fake IFD"
default y if !HAVE_IFD_BIN
help
If you don't have an Intel Firmware Descriptor (ifd.bin) for your
board, you can select this option and coreboot will build without it.
Though, the resulting coreboot.rom will not contain all parts required
to get coreboot running on your board. You can however write only the
BIOS section to your board's flash ROM and keep the other sections
untouched. Unfortunately the current version of flashrom doesn't
support this yet. But there is a patch pending [1].
WARNING: Never write a complete coreboot.rom to your flash ROM if it
was built with a fake IFD. It just won't work.
[1] http://www.flashrom.org/pipermail/flashrom/2013-June/011083.html
config IFD_BIOS_SECTION
depends on BUILD_WITH_FAKE_IFD
string
default ""
config IFD_ME_SECTION
depends on BUILD_WITH_FAKE_IFD
string
default ""
config IFD_PLATFORM_SECTION
depends on BUILD_WITH_FAKE_IFD
string
default ""
config IFD_BIN_PATH
string "Path to intel firmware descriptor"
depends on !BUILD_WITH_FAKE_IFD
default "3rdparty/mainboard/$(MAINBOARDDIR)/descriptor.bin"
Move baytrail-specific config to baytrail. Stop polluting first screen of all boards. Change-Id: I1ab88075722f7f0d63550010e7c645281603c9c3 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6548 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-08-09 07:16:10 +02:00
config HAVE_REFCODE_BLOB
depends on ARCH_X86
bool "An external reference code blob should be put into cbfs."
default n
help
The reference code blob will be placed into cbfs.
if HAVE_REFCODE_BLOB
config REFCODE_BLOB_FILE
string "Path and filename to reference code blob."
default "refcode.elf"
help
The path and filename to the file to be added to cbfs.
endif # HAVE_REFCODE_BLOB
baytrail: add initial support The initial Bay Trail code is intended to support the mobile and desktop version of Bay Trail. This support can train memory and execute through ramstage. However, the resource allocation is not curently handled correctly. The MRC cache parameters are successfully saved and reused after the initial cold boot. BUG=chrome-os-partner:22292 BRANCH=None TEST=Built and booted on a reference board through ramstage. Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168387 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4847 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-09-07 07:41:48 +02:00
endif
Reference in a new issue Copy permalink