diff --git a/Documentation/Intel/Board/board.html b/Documentation/Intel/Board/board.html deleted file mode 100644 index 0d4631ad51..0000000000 --- a/Documentation/Intel/Board/board.html +++ /dev/null @@ -1,239 +0,0 @@ - - - - Board - - - -

x86 Board Development

-

- Board development requires System-on-a-Chip (SoC) support. - The combined steps are listed - here. - The development steps for the board are listed below: -

-
    -
  1. Required Files
    2. -
  2. Enable Serial Output
    3. -
  3. Load the Memory Timing Data
    4. -
  4. Disable the PCI devices
    5. -
  5. ACPI Tables
    6. -
- - -
-

Required Files

-

- Create the board directory as src/mainboard/<Vendor>/<Board>. -

- -

- The following files are required to build a new board: -

-
    -
  1. Kconfig.name - Defines the Kconfig value for the board
    2. -
  2. Kconfig -
      -
    1. Selects the SoC for the board and specifies the SPI flash size -
        -
      1. BOARD_ROMSIZE_KB_<Size>
        2. -
      2. SOC_<Vendor>_<Chip Family>
        3. -
      -
      2. -
    2. Declare the Kconfig values for: -
        -
      1. MAINBOARD_DIR
        2. -
      2. MAINBOARD_PART_NUMBER
        3. -
      3. MAINBOARD_VENDOR
        4. -
      -
      3. -
    -
    3. -
  3. devicetree.cb - Enable root bridge and serial port -
      -
    1. The first line must be "chip soc/Intel/<soc family>"; - this path is used by the generated static.c to include the chip.h - header file -
      2. -
    -
    4. -
  4. romstage.c -
      -
    1. Add routine mainboard_romstage_entry which calls romstage_common
      2. -
    -
    5. -
  5. Configure coreboot build: -
      -
    1. Set LOCALVERSION
      2. -
    2. Select vendor for the board
      3. -
    3. Select the board
      4. -
    4. CBFS_SIZE = 0x00100000
      5. -
    5. Set the CPU_MICROCODE_CBFS_LEN
      6. -
    6. Set the CPU_MICROCODE_CBFS_LOC
      7. -
    7. Set the FSP_IMAGE_ID_STRING
      8. -
    8. Set the FSP_LOC
      9. -
    9. No payload
      10. -
    10. Choose the default value for all other options
      11. -
    -
    6. -
- - -
-

Enable Serial Output

-

- Use the following steps to enable serial output: -

-
    -
  1. Implement the car_mainboard_pre_console_init routine in the com_init.c - file: -
      -
    1. Power on and enable the UART controller
      2. -
    2. Connect the UART receive and transmit data lines to the - appropriate SoC pins -
      3. -
    -
    2. -
  2. Add Makefile.inc -
      -
    1. Add com_init.c to romstage
      2. -
    -
    3. -
- - -
-

Memory Timing Data

-

- Memory timing data is located in the flash. This data is in the format of - serial presence detect - (SPD) data. - Use the following steps to load the SPD data: -

-
    -
  1. Edit Kconfig to add the DISPLAY_SPD_DATA" value which enables the - display of the SPD data being passed to MemoryInit -
    2. -
  2. Create an "spd" subdirectory
    3. -
  3. Create an spd/spd.c file for the SPD implementation -
      -
    1. Implement the mainboard_fill_spd_data routine -
        -
      1. Read the SPD data either from the spd.bin file or using I2C or SMBUS
        2. -
      2. Fill in the pei_data structure with SPD data for each of the DIMMs
        3. -
      3. Set the DIMM channel configuration
        4. -
      -
      2. -
    -
    4. -
  4. Add an .spd.hex file containing the memory timing data to the spd subdirectory
    5. -
  5. Create spd/Makefile.inc -
      -
    1. Add spd.c to romstage
      2. -
    2. Add the .spd.hex file to SPD_SOURCES
      3. -
    -
    6. -
  6. Edit Makefile.inc to add the spd subdirectory
    7. -
  7. Edit romstage.c -
      -
    1. Call mainboard_fill_spd_data
      2. -
    2. Add mainboard_memory_init_params to copy the SPD and DRAM - configuration data from the pei_data structure into the UPDs - for MemoryInit -
      3. -
    -
    8. -
  8. Edit devicetree.cb -
      -
    1. Include the UPD parameters for MemoryInit except for: -
        -
      • Address of SPD data
        • -
      • DRAM configuration set above
        • -
      -
      2. -
    -
    9. -
  9. A working FSP - MemoryInit - routine is required to complete debugging
    10. -
  10. Debug the result until port 0x80 outputs -
      -
    1. 0x34: - - Just after entering - raminit -
      2. -
    2. 0x36: - - Just before displaying the - UPD parameters - for FSP MemoryInit -
      3. -
    3. 0x92: POST_FSP_MEMORY_INIT - - Just before calling FSP - MemoryInit -
      4. -
    4. 0x37: - - Just after returning from FSP - MemoryInit -
      5. -
    -
    11. -
  11. Continue debugging with CONFIG_DISPLAY_HOBS enabled until TempRamExit is called
    12. -
- - - -
-

Disable PCI Devices

-

- Ramstage's BS_DEV_ENUMERATE state displays the PCI vendor and device IDs for all - of the devices in the system. Edit the devicetree.cb file: -

-
    -
  1. Edit the devicetree.cb file: -
      -
    1. Add an entry for a PCI device.function and turn it off. The entry - should look similar to: -
      device pci 14.0 off end
      -
      2. -
    2. Turn on the devices for: -
        -
      • Memory Controller
        • -
      • Debug serial device
        • -
      -
      3. -
    -
    2. -
  2. Debug until the BS_DEV_ENUMERATE state shows the proper state for all of the devices
    3. -
- - - -
-

ACPI Tables

-
    -
  1. Edit Kconfig -
      -
    1. Add "select HAVE_ACPI_TABLES"
      2. -
    -
    2. -
  2. Add the acpi_tables.c module: -
      -
    1. Include soc/acpi.h
      2. -
    2. Add the acpi_create_fadt routine -
        -
      1. fill in the ACPI header
        2. -
      2. Call the acpi_fill_fadt routine
        3. -
      -
      3. -
    -
    3. -
  3. Add the dsdt.asl module: -
    4. -
- - - -
-

Modified: 20 February 2016

- - diff --git a/Documentation/Intel/Board/galileo.html b/Documentation/Intel/Board/galileo.html deleted file mode 100644 index f7edf6e8ee..0000000000 --- a/Documentation/Intel/Board/galileo.html +++ /dev/null @@ -1,113 +0,0 @@ - - - - Galileo - - - -

Intel® Galileo Development Board

- - - - - -
Galileo Gen 2 - The Intel® Galileo Gen 2 mainboard code was developed along with the Intel® - Quark™ SoC: - -
- - - -
-

Galileo Board Documentation

- - -

Galileo Gen 2 Board Documentation

- - -

Galileo Gen 1 Board Documentation

- - - - -
-

Debug Tools

- - - -
-

Modified: 29 February 2016

- - diff --git a/Documentation/Intel/SoC/quark.html b/Documentation/Intel/SoC/quark.html deleted file mode 100644 index c3eead2e33..0000000000 --- a/Documentation/Intel/SoC/quark.html +++ /dev/null @@ -1,220 +0,0 @@ - - - - Quark™ SoC - - - -

Intel® Quark™ SoC

- - - - - -
Quark Block Diagram - The Quark™ SoC code was developed using the - Galileo Gen 2 - board: - -
- - - -
-

Quark™ Documentation

- - - - -
-

Quark™ EDK2 CorebootPayloadPkg

-

-Build Instructions: -

-
    -
  1. Set up build environment
    2. -
  2. Linux (assumes GCC48): -
    build  -p CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc  -a IA32  \
-    -t GCC48  -b DEBUG  -DDEBUG_PROPERTY_MASK=0x27  \
-    -DDEBUG_PRINT_ERROR_LEVEL=0x80000042  -DSHELL_TYPE=BUILD_SHELL  \
-    -DMAX_LOGICAL_PROCESSORS=1
-ls Build/CorebootPayloadPkgIA32/DEBUG_GCC48/FV/UEFIPAYLOAD.fd
-
    -
    3. -
  3. Windows (assumes Visual Studio 2015): -
    build  -p CorebootPayloadPkg\CorebootPayloadPkgIa32.dsc  -a IA32  -t VS2015x86  -b DEBUG  -DDEBUG_PROPERTY_MASK=0x27  -DDEBUG_PRINT_ERROR_LEVEL=0x80000042  -DSHELL_TYPE=BUILD_SHELL  -DMAX_LOGICAL_PROCESSORS=1
-dir Build\CorebootPayloadPkgIA32\DEBUG_VS2015x86\FV\UEFIPAYLOAD.fd
-
    -
    4. -
  4. In the .config for coreboot, set the following Kconfig values: - -
    5. -
  5. Build coreboot
    6. -
  6. Copy the image build/coreboot.rom into flash
    7. -
- - - -
-

Quark™ EDK2 Build Environment

-

- Use the following steps to setup a build environment: -

-
    -
  1. Get the EDK2 sources: -
      -
    1. EDK2: git clone https://github.com/tianocore/edk2.git
      2. -
    2. EDK2-non-osi: git clone https://github.com/tianocore/edk2-non-osi.git
      3. -
    3. Win32 BaseTools: git clone https://github.com/tianocore/edk2-BaseTools-win32.git
      4. -
    -
    2. -
  2. Set up a build window: - -
    3. -
- - - -
-

Quark™ FSP

-

-Getting the Quark FSP source: -

-
    -
  1. Set up an EDK-II Build Environment
    2. -
  2. cd edk2
    3. -
  3. mkdir QuarkFspPkg
    4. -
  4. cd QuarkFspPkg
    5. -
  5. Use git to clone QuarkFspPkg into the QuarkFpsPkg directory (.)
    6. -
- -

Building QuarkFspPkg

-

-There are two versions of FSP: FSP 1.1 and FSP 2.0. There are also two -different implementations of FSP, one using subroutines without SEC and -PEI core and the original implementation which relies on SEC and PEI core. -Finally there are two different build x86 types release (r32) and debug (d32). -

-

Note that the subroutine implementations are a work in progress.

-

-Build commands shown building debug FSP: -

- - -

Copying FSP files into coreboot Source Tree

-

-There are some helper scripts to copy the FSP output into the coreboot -source tree. The parameters to these scripts are: -

-
    -
  1. EDK2 tree root
    2. -
  2. coreboot tree root
    3. -
  3. Build type: DEBUG or RELEASE
    4. -
-

-Script files: -

- - - -
-

Quark™ EDK2 BIOS

-

-Build Instructions: -

-
    -
  1. Set up build environment
    2. -
  2. Build the image: - -
    3. -
- -

-Documentation: -

- - - - -
-

Modified: 17 May 2016

- - diff --git a/Documentation/Intel/SoC/soc.html b/Documentation/Intel/SoC/soc.html deleted file mode 100644 index 8d565d52fe..0000000000 --- a/Documentation/Intel/SoC/soc.html +++ /dev/null @@ -1,730 +0,0 @@ - - - - SoC - - - -

x86 System on a Chip (SoC) Development

-

- SoC development is best done in parallel with development for a specific - board. The combined steps are listed - here. - The development steps for the SoC are listed below: -

-
    -
  1. FSP 1.1 required files
    2. -
  2. SoC Required Files
    3. -
  3. Start Booting
    4. -
  4. Early Debug
    5. -
  5. Bootblock
    6. -
  6. TempRamInit
    7. -
  7. Romstage -
      -
    1. Enable Serial Output"
      2. -
    2. Get the Previous Sleep State
      3. -
    3. Add the MemoryInit Support
      4. -
    4. Disable the Shadow ROM
      5. -
    -
    8. -
  8. Ramstage -
      -
    1. Start Device Tree Processing
      2. -
    2. Set up the Memory Map"
      3. -
    -
    9. -
  9. ACPI Tables
    10. -
  10. Legacy Hardware
    11. -
- - -
-

Required Files

-

- Create the directory as src/soc/<Vendor>/<Chip Family>. -

- -

- The following files are required to build a new SoC: -

- - - -
-

Start Booting

-

- Some SoC parts require additional firmware components in the flash. - This section describes how to add those pieces. -

- -

Intel Firmware Descriptor

-

- The Intel Firmware Descriptor (IFD) is located at the base of the flash part. - The following command overwrites the base of the flash image with the Intel - Firmware Descriptor: -

-
dd if=descriptor.bin of=build/coreboot.rom conv=notrunc >/dev/null 2>&1
- - -

Management Engine Binary

-

- Some SoC parts contain and require that the Management Engine (ME) be running - before it is possible to bring the x86 processor out of reset. A binary file - containing the management engine code must be added to the firmware using the - ifdtool. The following commands add this binary blob: -

-
util/ifdtool/ifdtool -i ME:me.bin  build/coreboot.rom
-mv build/coreboot.rom.new build/coreboot.rom
-
- - -

Early Debug

-

- Early debugging between the reset vector and the time the serial port is enabled - is most easily done by writing values to port 0x80. -

- - -

Success

-

- When the reset vector is successfully invoked, port 0x80 will output the following value: -

- - - -
-

Bootblock

-

- Implement the bootblock using the following steps: -

-
    -
  1. Create the directory as src/soc/<Vendor>/<Chip Family>/bootblock
    2. -
  2. Add the timestamp.inc file which initializes the floating point registers and saves - the initial timestamp. -
    3. -
  3. Add the bootblock.c file which: -
      -
    1. Enables memory-mapped PCI config access
      2. -
    2. Updates the microcode by calling intel_update_microcode_from_cbfs
      3. -
    3. Enable ROM caching
      4. -
    -
    4. -
  4. Edit the src/soc/<Vendor>/<Chip Family>/Kconfig file -
      -
    1. Add the BOOTBLOCK_CPU_INIT value to point to the bootblock.c file
      2. -
    2. Add the CHIPSET_BOOTBLOCK_INCLUDE value to point to the timestamp.inc file
      3. -
    -
    5. -
  5. Edit the src/soc/<Vendor>/<Chip Family>/Makefile.inc file -
      -
    1. Add the bootblock subdirectory
      2. -
    -
    6. -
  6. Edit the src/soc/<Vendor>/<Chip Family>/memmap.c file -
      -
    1. Add the fsp/memmap.h include file
      2. -
    -
    7. -
  7. Add the necessary .h files to define the necessary values and structures
    8. -
  8. When successful port 0x80 will output the following values: -
      -
    1. 0x01: POST_RESET_VECTOR_CORRECT - - Bootblock successfully executed the - reset vector - and entered the 16-bit code at - _start -
      2. -
    2. 0x10: POST_ENTER_PROTECTED_MODE - - Bootblock executing in - 32-bit mode -
      3. -
    3. 0x10 - Verstage/romstage reached 32-bit mode
      4. -
    -
    9. -
- -

- Build Note: The following files are included into the default bootblock image: -

- - - -
-

TempRamInit

-

- Enable the call to TempRamInit in two stages: -

-
    -
  1. Finding the FSP binary in the read-only CBFS region
    2. -
  2. Call TempRamInit
    3. -
- - -

Find FSP Binary

-

-Use the following steps to locate the FSP binary: -

-
    -
  1. Edit the src/soc/<Vendor>/<Chip Family>/Kconfig file -
      -
    1. Add "select USE_GENERIC_FSP_CAR_INC" to enable the use of - src/drivers/intel/fsp1_1/cache_as_ram.inc -
      2. -
    2. Add "select SOC_INTEL_COMMON" to enable the use of the files from src/soc/intel/common -
      3. -
    -
    2. -
  2. Debug the result until port 0x80 outputs -
      -
    1. 0x90: POST_FSP_TEMP_RAM_INIT - - Just before calling - TempRamInit -
      2. -
    2. Alternating 0xba and 0x01 - The FSP image was not found
      3. -
    -
    3. -
  3. Add the FSP binary file to the flash image
    4. -
  4. Set the following Kconfig values: - -
    5. -
  5. Debug the result until port 0x80 outputs -
      -
    1. 0x90: POST_FSP_TEMP_RAM_INIT - - Just before calling - TempRamInit -
      2. -
    2. Alternating 0xbb and 0x02 - TempRamInit executed, no CPU microcode update found
      3. -
    -
    6. -
- - -

Calling TempRamInit

-

-Use the following steps to debug the call to TempRamInit: -

-
    -
  1. Add the CPU microcode update file -
      -
    1. Add the microcode file with the following command -
      util/cbfstool/cbfstool build/coreboot.rom add -t microcode -n cpu_microcode_blob.bin -b <base address> -f cpu_microcode_blob.bin
      -
      2. -
    2. Set the Kconfig values -
        -
      • CONFIG_CPU_MICROCODE_CBFS_LOC set to the value from the previous step
        • -
      • CONFIG_CPU_MICROCODE_CBFS_LEN
        • -
      -
      3. -
    -
    2. -
  2. Debug the result until port 0x80 outputs -
      -
    1. 0x90: POST_FSP_TEMP_RAM_INIT - - Just before calling - TempRamInit -
      2. -
    2. 0x2A - Just before calling - cache_as_ram_main - which is the start of the verstage code which may be part of romstage -
      3. -
    -
    3. -
- - -
-

Romstage

- -

Serial Output

-

- The following steps add the serial output support for romstage: -

-
    -
  1. Create the romstage subdirectory
    2. -
  2. Add romstage/romstage.c -
      -
    1. Program the necessary base addresses
      2. -
    2. Disable the TCO
      3. -
    -
    3. -
  3. Add romstage/Makefile.inc -
      -
    1. Add romstage.c to romstage
      2. -
    -
    4. -
  4. Add gpio configuration support if necessary
    5. -
  5. Add the necessary .h files to support the build
    6. -
  6. Update Makefile.inc -
      -
    1. Add the romstage subdirectory
      2. -
    2. Add the gpio configuration support file to romstage
      3. -
    -
    7. -
  7. Set the necessary Kconfig values to enable serial output: - -
    8. -
- - -

Determine Previous Sleep State

-

- The following steps implement the code to get the previous sleep state: -

-
    -
  1. Implement the fill_power_state routine which determines the previous sleep state
    2. -
  2. Debug the result until port 0x80 outputs -
      -
    1. 0x32: - - Just after entering - romstage_common -
      2. -
    2. 0x33 - Just after calling - soc_pre_ram_init -
      3. -
    3. 0x34: - - Just after entering - raminit -
      4. -
    -
- - -

MemoryInit Support

-

- The following steps implement the code to support the FSP MemoryInit call: -

-
    -
  1. Add the chip.h header file to define the UPD values which get passed - to MemoryInit. Skip the values containing SPD addresses and DRAM - configuration data which is determined by the board. -

    - Build Note: The src/mainboard/<Vendor>/<Board>/devicetree.cb - file specifies the default values for these parameters. The build - process creates the static.c module which contains the config data - structure containing these values. -

    -
    2. -
  2. Edit romstage/romstage.c -
      -
    1. Implement the romstage/romstage.c/soc_memory_init_params routine to - copy the values from the config structure into the UPD structure -
      2. -
    2. Implement the soc_display_memory_init_params routine to display - the updated UPD parameters by calling fsp_display_upd_value -
      3. -
    -
    3. -
- - -

Disable Shadow ROM

-

- A shadow of the SPI flash part is mapped from 0x000e0000 to 0x000fffff. - This shadow needs to be disabled to allow RAM to properly respond to - this address range. -

-
    -
  1. Edit romstage/romstage.c and add the soc_after_ram_init routine
    2. -
- - -
-

Ramstage

- -

Start Device Tree Processing

-

- The src/mainboard/<Vendor>/<Board>/devicetree.cb file drives the - execution during ramstage. This file is processed by the util/sconfig utility - to generate build/mainboard/<Vendor>/<Board>/static.c. The various - state routines in - src/lib/hardwaremain.c - call dev_* routines which use the tables in static.c to locate operation tables - associated with the various chips and devices. After location the operation - tables, the state routines call one or more functions depending upon the - state of the state machine. -

- -

Chip Operations

-

- Kick-starting the ramstage state machine requires creating the operation table - for the chip listed in devicetree.cb: -

-
    -
  1. Edit src/soc/<SoC Vendor>/<SoC Family>/chip.c: -
      -
    1. - This chip's operation table has the name - soc_<SoC Vendor>_<SoC Family>_ops which is derived from the - chip path specified in the devicetree.cb file. -
      2. -
    2. Use the CHIP_NAME macro to specify the name for the chip
      3. -
    3. For FSP 1.1, specify a .init routine which calls intel_silicon_init
      4. -
    -
    2. -
  2. Edit src/soc/<SoC Vendor>/<SoC Family>/Makefile.inc and add chip.c to ramstage
    3. -
- -

Domain Operations

-

- coreboot uses the domain operation table to initiate operations on all of the - devices in the domain. By default coreboot enables all PCI devices which it - finds. Listing a device in devicetree.cb gives the board vendor control over - the device state. Non-PCI devices may also be listed under PCI device such as - the LPC bus or SMbus devices. -

-
    -
  1. Edit src/soc/<SoC Vendor>/<SoC Family>/chip.c: -
      -
    1. - The domain operation table is typically placed in - src/soc/<SoC Vendor>/<SoC Family>/chip.c. - The table typically looks like the following: -
      static struct device_operations pci_domain_ops = {
-	.read_resources	= pci_domain_read_resources,
-	.set_resources	= pci_domain_set_resources,
-	.scan_bus	= pci_domain_scan_bus,
-};
-
      -
      2. -
    2. - Create a .enable_dev entry in the chip operations table which points to a - routine which sets the domain table for the device with the DEVICE_PATH_DOMAIN. -
      	if (dev->path.type == DEVICE_PATH_DOMAIN) {
-		dev->ops = &pci_domain_ops;
-	}
-
      -
      3. -
    3. - During the BS_DEV_ENUMERATE state, ramstage now display the device IDs - for the PCI devices on the bus. -
      4. -
    -
    2. -
  2. Set CONFIG_DEBUG_BOOT_STATE=y in the .config file
    3. -
  3. - Debug the result until the PCI vendor and device IDs are displayed - during the BS_DEV_ENUMERATE state. -
    4. -
- - -

PCI Device Drivers

-

- PCI device drivers consist of a ".c" file which contains a "pci_driver" data - structure at the end of the file with the attribute tag "__pci_driver". This - attribute tag places an entry into a link time table listing the various - coreboot device drivers. -

-

- Specify the following fields in the table: -

-
    -
  1. .vendor - PCI vendor ID value of the device
    2. -
  2. .device - PCI device ID value of the device or
    - .devices - Address of a zero terminated array of PCI device IDs -
    3. -
  3. .ops - Operations table for the device. This is the address - of a "static struct device_operations" data structure specifying - the routines to execute during the different states and sub-states - of ramstage's processing. -
    4. -
  4. Turn on the device in mainboard/<Vendor>/<Board>/devicetree.cb
    5. -
  5. - Debug until the device is on and properly configured in coreboot and - usable by the payload -
    6. -
- -

Subsystem IDs

-

- PCI subsystem IDs are assigned during the BS_DEV_ENABLE state. The device - driver may use the common mechanism to assign subsystem IDs by adding - the ".ops_pci" to the pci_driver data structure. This field points to - a "struct pci_operations" that specifies a routine to set the subsystem - IDs for the device. The routine might look something like this: -

-
static void pci_set_subsystem(struct device *dev, unsigned vendor, unsigned device)
-{
-	if (!vendor || !device) {
-		vendor = pci_read_config32(dev, PCI_VENDOR_ID);
-		device = vendor >> 16;
-	}
-	printk(BIOS_SPEW,
-		"PCI: %02x:%02x:%d subsystem vendor: 0x%04x, device: 0x%04x\n",
-		0, PCI_SLOT(dev->path.pci.devfn), PCI_FUNC(dev->path.pci.devfn),
-		vendor & 0xffff, device);
-	pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID,
-			((device & 0xffff) << 16) | (vendor & 0xffff));
-}
-
- - - -

Set up the Memory Map

-

- The memory map is built by the various PCI device drivers during the - BS_DEV_RESOURCES state of ramstage. The northcluster driver will typically - specify the DRAM resources while the other drivers will typically specify - the IO resources. These resources are hung off the struct device *data structure by - src/device/device_util.c/new_resource. -

-

- During the BS_WRITE_TABLES state, coreboot collects these resources and - places them into a data structure identified by LB_MEM_TABLE. -

-

- Edit the device driver file: -

-
    -
  1. - Implement a read_resources routine which calls macros defined in - src/include/device/device.h - like: - -
    2. -
- -

- Testing: Verify that the resources are properly displayed by coreboot during the BS_WRITE_TABLES state. -

- - - -
-

ACPI Tables

-

- One of the payloads that needs ACPI tables is the EDK2 CorebootPayloadPkg. -

- -

FADT

-

- The EDK2 module - CorebootModulePkg/Library/CbParseLib/CbParseLib.c - requires that the FADT contains the values in the table below. - These values are placed into a HOB identified by - gUefiAcpiBoardInfoGuid - by routine - CorebootModulePkg/CbSupportPei/CbSupportPei/CbPeiEntryPoint. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
coreboot FieldEDK2 FieldgUefiAcpiBoardInfoGuidUse - - ACPI Spec. - Section -
gpe0_blk
gpe0_blk_len		Gpe0Blk
Gpe0BlkLen		 - PmGpeEnBase - Shutdown4.8.4.1
pm1a_cnt_blkPm1aCntBlkPmCtrlRegBase - Shutdown
- Suspend - 		4.8.3.2.1
pm1a_evt_blkPm1aEvtBlkPmEvtBaseShutdown4.8.3.1.1
pm_tmr_blkPmTmrBlkPmTimerRegBase - Timer - 4.8.3.3
reset_reg.ResetReg.AddressResetRegAddress - Cold - and - Warm - resets - 4.3.3.6
reset_valueResetValueResetValue - Cold - and - Warm - resets - 4.8.3.6
-

- The EDK2 data structure is defined in - MdeModulePkg/Include/IndustryStandard/Acpi61.h - The coreboot data structure is defined in - src/arch/x86/include/arch/acpi.h -

- -
    -
  1. - Select HAVE_ACPI_TABLES - in the board's Kconfig file -
    2. -
  2. Create a acpi.c module: -
      -
    1. Add the acpi_fill_fadt routine and initialize the values above
      2. -
    -
    3. -
- - - -
-

Legacy Hardware

-

- One of the payloads that needs legacy hardare is the EDK2 CorebootPayloadPkg. -

- - - - - - - - - - - - - - - - - - - - - - - -
PeripheralUse8259 Interrupt VectorIDT Base OffsetInterrupt Handler
- 8254 - Programmable Interval Timer - - EDK2: PcAtChipsetPkg/8254TimerDxe/Timer.c - 00x340 - TimerInterruptHandler -
- 8259 - Programmable Interrupt Controller - - EDK2: PcAtChipsetPkg/8259InterruptControllerDxe/8259.c - - Master interrupts: 0, 2 - 7
- Slave interrupts: 8 - 15
- Interrupt vector 1 is never generated, the cascaded input generates interrupts 8 - 15 - 		- Master: 0x340, 0x350 - 0x378
- Slave: 0x380 - 0x3b8
- Interrupt descriptors are 8 bytes each - 		 
- -
-

Modified: 4 March 2016

- - diff --git a/Documentation/Intel/development.html b/Documentation/Intel/development.html deleted file mode 100644 index 92b1d4be8d..0000000000 --- a/Documentation/Intel/development.html +++ /dev/null @@ -1,377 +0,0 @@ - - - - Development - - - -

Intel® x86 coreboot/FSP Development Process

-

- The x86 development process for coreboot is broken into the following components: -

- -

- The development process has two main phases: -

-
    -
  1. Minimal coreboot; This phase is single threaded
    2. -
  2. Adding coreboot features
    3. -
- -

Minimal coreboot

-

- The combined steps below describe how to bring up a minimal coreboot for a - system-on-a-chip (SoC) and a development board: -

- - - - -
The initial coreboot steps are single threaded! - The initial minimal FSP development is also single threaded. - Progress can speed up by adding more developers after the minimal coreboot/FSP - implementation reaches the payload. -
-
    -
  1. Get the necessary tools: - -
    2. -
  2. Build the cross tools for i386: - -
    3. -
  3. Get something to build: -
      -
    1. FSP 1.1 required files
      2. -
    2. SoC required files
      3. -
    3. Board required files
      4. -
    -
    4. -
  4. Get result to start booting
    5. -
  5. Early Debug
    6. -
  6. Implement and debug the bootblock code
    7. -
  7. Implement and debug the call to TempRamInit
    8. -
  8. Enable the serial port -
      -
    1. Power on, enable and configure GPIOs for the - debug serial UART -
      2. -
    2. Add the serial outupt - support to romstage -
      3. -
    -
    9. -
  9. Enable coreboot/FSP debugging
    10. -
  10. Determine the Previous Sleep State
    11. -
  11. Enable DRAM: -
      -
    1. Implement the SoC - MemoryInit - Support -
      2. -
    2. Implement the board support to read the - Memory Timing Data -
      3. -
    -
    12. -
  12. Disable the - Shadow ROM -
    13. -
  13. Enable CONFIG_DISPLAY_MTRRS to verify the MTRR configuration
    14. -
  14. - Implement the .init routine for the - chip operations - structure which calls FSP SiliconInit -
    15. -
  15. - Start ramstage's - device tree processing - to display the PCI vendor and device IDs -
    16. -
  16. - Disable the - PCI devices -
    17. -
  17. - Implement the - memory map -
    18. -
  18. coreboot should now attempt to load the payload
    19. -
- - - -

Add coreboot Features

-

- Most of the coreboot development gets done in this phase. Implementation tasks in this - phase are easily done in parallel. -

- - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Features

SoCWhereTesting
8254 Programmable Interval TimerLegacy hardware supportCorebootPayloadPkg gets to shell prompt
8259 Programmable Interrupt ControllerLegacy hardware supportCorebootPayloadPkg gets to shell prompt
Cache-as-RAM - Find - FSP binary: - cache_as_ram.inc
- Enable: FSP 1.1 TempRamInit - called from - cache_as_ram.inc
- Disable: FSP 1.1 TempRamExit called from - after_raminit.S
- 		FindFSP: POST code 0x90 - (POST_FSP_TEMP_RAM_INIT) - is displayed
- Enable: POST code - 0x2A - is displayed
- Disable: CONFIG_DISPLAY_MTRRS=y, MTRRs displayed after call to TempRamExit -
Memory Map - Implement a device driver for the - north cluster - coreboot displays the memory map correctly during the BS_WRITE_TABLES state
MTRRs - Set values: src/drivers/intel/fsp1_1/stack.c/setup_stack_and_mtrrs
- Load values: src/drivers/intel/fsp1_1/after_raminit.S - 		Set: Post code 0x91 - (POST_FSP_TEMP_RAM_EXIT) - is displayed by - after_raminit.S
- Load: Post code 0x3C is displayed by - after_raminit.S
- and CONFIG_DISPLAY_MTRRS=y displays the correct memory regions
PCI Device SupportImplement a PCI device driverThe device is detected by coreboot and usable by the payload
Ramstage state machine - Implement the chip and domain operations to start the - device tree - processing - - During the BS_DEV_ENUMERATE state, ramstage now display the device IDs - for the PCI devices on the bus. -
ROM Shadow
0x000E0000 - 0x000FFFFF		 - Disable: src/soc/<Vendor>/<Chip Family>/romstage/romstage.c/soc_after_ram_init routine - Operates as RAM: Writes followed by a read to the 0x000E0000 - 0x000FFFFF region returns the value written
BoardWhereTesting
Device Tree - List PCI vendor and device IDs by starting - the device tree processing
- Disable PCI devices
- Enable: Implement a PCI device driver - 		- List: BS_DEV_ENUMERATE state displays PCI vendor and device IDs
- Disable: BS_DEV_ENUMERATE state shows the devices as disabled
- Enable: BS_DEV_ENUMERATE state shows the device as on and the device works for the payload -
DRAM - Load SPD data: src/soc/mainboard/<Vendor>/<Board>/spd/spd.c
- UPD Setup: -
    -
  • src/soc<Vendor>//<Chip Family>/romstage/romstage.c
    • -
  • src/mainboard/<Vendor>/<Board>/romstage.c
    • -
- FSP 1.1 MemoryInit called from src/drivers/intel/fsp1_1/raminit.c - 		Select the following Kconfig values -
    -
  • DISPLAY_HOBS
    • -
  • DISPLAY_UPD_DATA
    • -
- Testing successful if: -
    -
  • MemoryInit UPD values are correct
    • -
  • MemoryInit returns 0 (success) and
    • -
  • The message "ERROR - coreboot's requirements not met by FSP binary!" - is not displayed -
    • -
-
Serial Port - SoC Support
- Enable: src/soc/mainboard/<Board>/com_init.c/car_mainboard_pre_console_init - 		Debug serial output works
PayloadWhereTesting
ACPI Tables - SoC Support
- 		Verified by payload or OS
FSPWhereTesting
TempRamInitFSP TempRamInitFSP binary found: POST code 0x90 - (POST_FSP_TEMP_RAM_INIT) - is displayed
- TempRamInit successful: POST code - 0x2A - is displayed
-
MemoryInitSoC support
- Board support
- 		Select the following Kconfig values -
    -
  • DISPLAY_HOBS
    • -
  • DISPLAY_UPD_DATA
    • -
- Testing successful if: -
    -
  • MemoryInit UPD values are correct
    • -
  • MemoryInit returns 0 (success) and
    • -
  • The message "ERROR - coreboot's requirements not met by FSP binary!" - is not displayed -
    • -
-
TempRamExitsrc/drivers/intel/fsp1_1/after_raminit.SPost code 0x91 - (POST_FSP_TEMP_RAM_EXIT) - is displayed before calling TempRamExit by - after_raminit.S, - CONFIG_DISPLAY_MTRRS=y displays the correct memory regions and - Post code 0x39 is displayed by - after_raminit.S
-
SiliconInit - Implement the .init routine for the - chip operations structure - During BS_DEV_INIT_CHIPS state, SiliconInit gets called and returns 0x00000000
FspNotify - The code which calls FspNotify is located in - src/drivers/intel/fsp1_1/fsp_util.c. - The fsp_notify_boot_state_callback routine is called three times as specified - by the BOOT_STATE_INIT_ENTRY macros below the routine. - - The FspNotify routines are called during: -
    -
  • BS_DEV_RESOURCES - on exit
    • -
  • BS_PAYLOAD_LOAD - on exit
    • -
  • BS_OS_RESUME - on entry (S3 resume)
    • -
-
- - - -
-

Modified: 4 March 2016

- - diff --git a/Documentation/Intel/fsp1_1.html b/Documentation/Intel/fsp1_1.html deleted file mode 100644 index 94cb6bf8be..0000000000 --- a/Documentation/Intel/fsp1_1.html +++ /dev/null @@ -1,79 +0,0 @@ - - - - FSP 1.1 - - - -

FSP 1.1

- -

x86 FSP 1.1 Integration

-

- Firmware Support Package (FSP) integration requires System-on-a-Chip (SoC) - and board support. The combined steps are listed - here. - The development steps for FSP are listed below: -

-
    -
  1. Required Files
    2. -
  2. Add the FSP Binary File to the coreboot File System
    3. -
  3. Enable coreboot/FSP Debugging
    4. -
- -

- FSP Documentation: -

- - -
-

Required Files

-

coreboot Required Files

-
    -
  1. Create the following directories if they do not already exist: - -
    2. -
  2. - The following files may need to be copied from the FSP build or release into the - directories above if they are not present or are out of date: - -
    3. -
- - -
-

Add the FSP Binary File to coreboot File System

-

- Add the FSP binary to the coreboot flash image using the following command: -

-
util/cbfstool/cbfstool build/coreboot.rom add -t fsp -n fsp.bin -b <base address> -f fsp.bin
-

- This command relocates the FSP binary to the 4K byte aligned location in CBFS so that the - FSP code for TempRamInit may be executed in place. -

- - -
-

Enable coreboot/FSP Debugging

-

- Set the following Kconfig values: -

- - - -
-

Modified: 17 May 2016

- - diff --git a/Documentation/Intel/index.html b/Documentation/Intel/index.html deleted file mode 100644 index 9d8aad05e9..0000000000 --- a/Documentation/Intel/index.html +++ /dev/null @@ -1,128 +0,0 @@ - - - - Intel® x86 - - - -

Intel® x86

- -

Intel® x86 Boards

- - -

Intel® x86 SoCs

- - - - -
-

x86 coreboot Development

- - - - -
-

Payload Development

- - - - -
-

Documentation

- - -

EDK-II Documentation

- - -

FSP Documentation

- - -

Feature Documentation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Feature/SpecificationLinux View/TestEDK-II View/Test
e820dmesg 
ACPIacpidump 
EDIDget-edid | parse-edid 
I2Ci2cdetect 
Multiprocessorlscpu 
PCIlspcipci
SMBIOSdmidecodesmbiosview
USBlsusb 
- -
-

Modified: 18 June 2016

- -