GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/arch/x86/bootblock_crt0.S

78 lines
2 KiB
ArmAsm
Raw Normal View History

arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
/*
* This is the modern bootblock. It is used by platforms which select
* C_ENVIRONMENT_BOOTBLOCK, and it prepares the system for C environment runtime
* setup. The actual setup is done by hardware-specific code.
*
* It provides a bootflow similar to other architectures, and thus is considered
* to be the modern approach.
*
* This file is part of the coreboot project.
*
* Copyright (C) 2015 Alexandru Gagniuc <mr.nuke.me@gmail.com>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
arch/x86: Add second paragraph to license header Change-Id: Ic1da46d2abc8d20987048e4ef1e7a776d0c685d6 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13555 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2016-02-02 14:14:44 +01:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
*/
bootblock_crt0: Use CR* macros from cpu/x86/cr.h Instead of re-defining the macros, include cpu/x86/cr.h in bootblock_crt0.S to re-use already defined macros for accessing CR* flags. Change-Id: Idade02f7a6bc880c9aad3bfacd05ac57b6d04e44 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/14359 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-04-14 02:15:36 +02:00
#include <cpu/x86/cr.h>
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
/*
* Include the old code for reset vector and protected mode entry. That code has
* withstood the test of time.
*/
#include <arch/x86/prologue.inc>
#include <cpu/x86/16bit/entry16.inc>
#include <cpu/x86/16bit/reset16.inc>
#include <cpu/x86/32bit/entry32.inc>
arch/x86: Add debug spinloop Conditionally add a debug spinloop to enable easy connection of JTAG debuggers. TEST=Build and run on Galileo Gen2 with a JTAG debugger. Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15127 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-07 17:45:17 +02:00
#if IS_ENABLED(CONFIG_BOOTBLOCK_DEBUG_SPINLOOP)
/* Wait for a JTAG debugger to break in and set EBX non-zero */
xor %ebx, %ebx
debug_spinloop:
cmp $0, %ebx
jz debug_spinloop
#endif
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
bootblock_protected_mode_entry:
arch/x86: Support "weak" BIST and timestamp save routines Not all x86 architectures support the mm register set. The default routine that saves BIST in mm0 and a "weak" routine that saves the TSC value in mm2:mm1. Select the Kconfig value BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to save the BIST and timestamp values. TEST=Build and run on Amenia and Galileo Gen2. Change-Id: I8119e74664ac3522c011767d424d441cd62545ce Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15126 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-06 03:41:00 +02:00
/* BIST result in eax */
movl %eax, %ebx
/* Get an early timestamp */
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
rdtsc
arch/x86: Support "weak" BIST and timestamp save routines Not all x86 architectures support the mm register set. The default routine that saves BIST in mm0 and a "weak" routine that saves the TSC value in mm2:mm1. Select the Kconfig value BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to save the BIST and timestamp values. TEST=Build and run on Amenia and Galileo Gen2. Change-Id: I8119e74664ac3522c011767d424d441cd62545ce Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15126 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-06 03:41:00 +02:00
#if IS_ENABLED(CONFIG_BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP)
lea 1f, %ebp
/* eax: Low 32-bits of timestamp
* ebx: BIST result
* ebp: return address
* edx: High 32-bits of timestamp
*/
jmp bootblock_save_bist_and_timestamp
1:
#else
movd %ebx, %mm0
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
movd %eax, %mm1
movd %edx, %mm2
arch/x86: Support "weak" BIST and timestamp save routines Not all x86 architectures support the mm register set. The default routine that saves BIST in mm0 and a "weak" routine that saves the TSC value in mm2:mm1. Select the Kconfig value BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to save the BIST and timestamp values. TEST=Build and run on Amenia and Galileo Gen2. Change-Id: I8119e74664ac3522c011767d424d441cd62545ce Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15126 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-06 03:41:00 +02:00
#endif
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
arch/x86: Enable SSE in bootblock_crt0.S Don't write reserved bits in the Quark platform. Follow the previous boot behavior and just enable SSE. TEST=Build and run on Galileo Gen2 Change-Id: Ib3143eff02b2610b595bd666c10d70e43103ccda Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15128 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-08 16:11:48 +02:00
#if IS_ENABLED(CONFIG_SSE)
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
enable_sse:
mov %cr4, %eax
arch/x86: Enable SSE in bootblock_crt0.S Don't write reserved bits in the Quark platform. Follow the previous boot behavior and just enable SSE. TEST=Build and run on Galileo Gen2 Change-Id: Ib3143eff02b2610b595bd666c10d70e43103ccda Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/15128 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-06-08 16:11:48 +02:00
or $CR4_OSFXSR, %ax
arch/x86: Implement minimal bootblock for C_ENVIRONMENT_BOTOBLOCK Some newer x86 systems can boot from non-memory-mapped boot media (e.g. EMMC). The bootblock may be backed by small amounts of SRAM, or other memory, similar to how most ARM chipsets work. In such cases, we may not have enough code space for romstage very early on. This means that CAR setup and early boot media (e.g. SPI, EMMC) drivers need to be implemented within the limited amount memory of storage available. Since the reset vector has to be contained in this early code memory, the bootblock is the best place to implement loading of other stages. Implement a bootblock which does the minimal initialization, up to, and including switch to protected mode. This then transfers control to platform-specific code. No stack is needed, and control is transferred via a "jmp" such that no stack operations are involved. Change-Id: I009b42b9a707cf11a74493bd4d8c189dc09b8ace Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: https://review.coreboot.org/13485 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-27 03:22:43 +01:00
mov %eax, %cr4
#endif /* IS_ENABLED(CONFIG_SSE) */
/* We're done. Now it's up to platform-specific code */
jmp bootblock_pre_c_entry
Reference in a new issue Copy permalink