Other SOC platforms need to handle the FspNotify calls in the same way
as Apollo Lake. Migrate the FspNotify calls into the FSP 2.0 driver.
Provide a platform callback to handle anything else that needs to be
done after the FspNotify call.
Display the MTRRs before the first call to fsp_notify.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Change-Id: I9a8dfd3d7eb3a51f9a1028b3ea4f3eeaa290857f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15855
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367379
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Move all FSP error handling into the FSP 2.0 driver. This removes the
need to implement error handling within the SOC code.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Change-Id: I6e1a768379944353c25ce2ee69f94d655028a411
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15853
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367378
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add support to display the HOBs returned by FSP:
* Add Kconfig value to enable HOB display
* Move hob_header, hob_resource and uuid_name structures into util.h
* Move hob_type enum into util.h
* Remove static from the debug utility functions
* Add fsp_ prefix to the debug utility functions
* Declare the debug utility functions in debug.h
* Add HOB type name table
* Add more GUID values
* Add new GUID name table for additional GUIDs
* Add routine to convert EDK-II GUID into a name
* Add SOC specific routine to handle unknown GUID types
* Add routine to convert HOB type into a name
* Add SOC specific routine to handle unknown HOB types
* Add routine to display the hobs
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Change-Id: If23692aa426606fe49018d06f358933b3ecd558a
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367376
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add UPD display support:
* Add a Kconfig value to enable UPD value display
* Add a routine to display a UPD value
* Add a call before MemoryInit to display the UPD parameters
* Add a routine to display the architectural parameters for MemoryInit
* Add a weak routine to display the other UPD parameters for MemoryInit
* Add a call before SiliconInit to display the UPD parameters
* Add a weak routine to display the UPD parameters for SiliconInit
TEST=Build and run on Galileo Gen2.
BUG=None
BRANCH=None
Change-Id: I651a56d57d635c682f206590d8d86854c7b4de24
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15847
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367375
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Display the MTRR values in the following locations:
* Before the call to FspMemoryInit to document coreboot settings
* After the call to FspMemoryInit
* Before the call to FspSiliconInit
* After the call to FspSiliconInit
* After the call to FspNotify
* Before the call to FspNotify added in patch 15855
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Change-Id: If3e99ec06c9df45e6185e33acc843b29630899ff
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15849
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367374
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Disable the chatty FSP behavior for normal builds. Use a Kconfig value
to enable the display of the FSP call entry points, the call parameters
and the returned status for MemoryInit, SiliconInit and FspNotify. The
debug code is placed into drivers/intel/fsp2_0/debug.c.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Change-Id: I18e207053ef6542912f0f0b8125e874888cb52fb
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15989
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367362
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(val & 4) == 1 is always false. Since val & 4 is either zero or
non-zero, just drop the second test (for "== 1").
Validated against the data sheet that this is really the right register,
bit and value.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ie2a8aa09bd9c7c43608bda49c9101a87b9bdcdad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1241864
Reviewed-on: https://review.coreboot.org/16009
Tested-by: build bot (Jenkins)
Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/367361
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This removes the newlines from all files found by the new
int-015-final-newlines script.
BUG=None
BRANCH=None
TEST=None
Change-Id: I89fcb55ff285e4793d7f057f684187359334cb70
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15975
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/366218
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Keep this enabled by default as most x86 platforms could have PCI-e
slots equipped with one of these Intel WiFi adapters.
The Kconfig entries under google boards had no function previously,
the variable was never referenced.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0dce909b07067eb4f23c89cddff32a004fdc52f0
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15931
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366216
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
If the system is in recovery, store the newly generated MRC data using a
dummy version which is not legit. This ensures that on next normal boot,
new MRC data will be generated and stored.
BUG=chrome-os-partner:55699
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15828
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ib13e8c978dc1b4fc8817fab16d0e606f210f2586
Reviewed-on: https://chromium-review.googlesource.com/364013
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Quark does not support the rdmsr and wrmsr instructions. In this case
use a SOC specific routine to support the setting of the MTRRs. Migrate
the code from FSP 1.1 to be x86 CPU common.
Since all rdmsr/wrmsr accesses are being converted, fix the build
failure for quark in lib/reg_script.c. Move the soc_msr_x routines and
their depencies from romstage/mtrr.c to reg_access.c.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15839
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibc68e696d8066fbe2322f446d8c983d3f86052ea
Reviewed-on: https://chromium-review.googlesource.com/363935
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The removal of ELOG_FLASH_BASE and ELOG_FLASH_SIZE resulted
in the FMAP region for the eventlog to be honored. However,
certain systems seem to have a large eventlog region that
wasn't being used in practice. Because of the malloc() in the
eventlog init sequence a large allocation was now being requested
that can exhaust the heap. Put back the 4KiB capacity until
the resource usage is fixed.
BUG=chrome-os-partner:55593
Change-Id: Ib54b396b48e5be80f737fc3feb0d58348c0d2844
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15835
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363386
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Separate NO_XIP_EARLY_STAGES from loading FSP-M into cache-as-RAM.
Quark executes romstage directly from the SPI flash part (in-place),
but loads FSP-M into ESRAM. This split occurs because ESRAM is too
small to hold everything while debugging.
Platforms executing FSP-M directly from the SPI flash need to select
FSP_M_XIP.
TEST=Build and run on Galileo Gen2.
Change-Id: Ib5313ae96dcec101510e82438b1889d315569696
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15848
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363382
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Now that FMAP is a first class citizen in coreboot
there's no reason to have alternate locations for ELOG.
If one wants eventlog support they need to specify the
ELOG entry in the FMAP. The one side effect is that
the code was previously limiting the size to 4KiB
because the default ELOG_AREA_SIZE was 4KiB. However,
that's no longer the case as the FMAP region size is
honored.
Change-Id: I4ce5f15032387155d2f56f0de61f2d85271ba606
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15814
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362768
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Ensure that the stack provided to FSPM doesn't overlap the current
program which is loading the FSPM component. If there is a conflict
that's an error since it could cause the current program to crash.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15746
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Change-Id: Ifff465266e5bb3cb3cf9b616d322a46199f802c7
Reviewed-on: https://chromium-review.googlesource.com/361779
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Utilizing the FSP revision while saving the memory training data is
important because it means when the FSP is updated the memory training
is redone. The previous implementation was just using '0' as a revision.
Because of that behavior a retrain would not have been done on an FSP
upgrade.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15744
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I1430bd78c770a840d2deff2476f47150c02cf27d
Reviewed-on: https://chromium-review.googlesource.com/361777
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The FSPS component loading was just loading to any memory address
listed in the header. That could be anywhere in the address space
including ramstage itself -- let alone corrupting the OS memory on
S3 resume. Remedy this by loading and relocating FSPS into cbmem.
The UEFI 2.4 header files include path are selected to provide the
types necessary for FSP relocation.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15742
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: John Zhao <john.zhao@intel.com>
Change-Id: Iaba103190731fc229566a3b0231cf967522040db
Reviewed-on: https://chromium-review.googlesource.com/361775
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: John Zhao <john.zhao@intel.com>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: John Zhao <john.zhao@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The previously implementation for loading the FSPM component didn't
handle platforms which expects FSPM to be XIP. For the non-XIP case,
romstage's address space wasn't fully being checked for overlaps.
Lastly, fixup the API as the range_entry isn't needed any longer.
This API change requires a apollolake to be updated as well.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15741
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I24d0c7d123d12f15a8477e1025bf0901e2d702e7
Reviewed-on: https://chromium-review.googlesource.com/361774
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The current FSP component loading mechanism doesn't handle all the
requirements actually needed. Two things need to be added:
1. XIP support for MemoryInit component
2. Relocating SiliconInit component to not corrupt OS memory.
In order to accommodate those requirements the validation
and header initialization needs to be a separate function.
Therefore, provide fsp_validate_component() to help achieve those
requirements.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15740
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I53525498b250033f3187c05db248e07b00cc934d
Reviewed-on: https://chromium-review.googlesource.com/361773
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of performing the same tasks in the chipset code move
the common sequences into the FSP 2.0 driver. This handles the
S3 paths as well as saving and restoring the memory data. The
chipset code can always override the settings if needed.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15739
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I098bf95139a0360f028a50aa50d16d264bede386
Reviewed-on: https://chromium-review.googlesource.com/361772
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The amount of reserved memory just below the DRAM limit in
32-bit space is defined in the FSP 2.0 specification within
the FSPM_ARCH_UPD structure. There's no need to make the
chipset code set the same value as needed for coreboot.
The chipset code can always change the value if it needs
after the common setting being applied.
Remove the call in soc/intel/apollolake as it's no longer
needed.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15738
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Change-Id: I69a1fee7a7b53c109afd8ee0f03cb8506584d571
Reviewed-on: https://chromium-review.googlesource.com/361771
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The gcc compiler treats sizeof(void) == 1. Therefore requesting
a 1 byte reservation in cbmem and writing a pointer into the
buffer returned is wrong. Fix the size of the request to be
32-bits because FSP 2.0 is in 32-bit space by definition. Also,
since the access to the field happens across stage boundaries
it's important to ensure fixed widths are used in case a later
stage has a different pointer bit width.
BUG=chrome-os-partner:52679
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15737
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ib4efc7d5369d44a995318aac6c4a7cfdc73e4a8c
Reviewed-on: https://chromium-review.googlesource.com/361770
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In case of elog not being stored in CBMEM, calculate flash offset by
using rdev_mmap instead of assuming that the entire flash is mapped just
below 4GiB. This allows custom mappings of flash to correctly convert
the flash offset to mmap address.
BUG=chrome-os-partner:54186
TEST=Verified behavior on reef. mosys able to read out the elog correctly.
Change-Id: I3eacd2c9266ecc3da1bd45c86ff9d0e8153ca3f2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15722
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361241
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
The SLEEP_STATE_x definitions in the chipsets utilizing
FSP 1.1. driver have the exact same values as the ACPI_Sx
definitions. The chipsets will be moved over subsequently,
but updating this first allows the per-chipset patches
to be isolated.
BUG=chrome-os-partner:54977
Change-Id: I383a9a732ef68bf2276f6149ffa5360bcdfb70b3
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15665
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-by: Lee Leahy <leroy.p.leahy@intel.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360825
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This driver enables the usage of an external RTC chip PCF8523 which is
connected to the I2C bus. The I2C address of this device is fixed.
One can change parameters in device tree so that the used setup can be
adapted in device tree to match the configuration of the device on the
mainboard.
BUG=None
BRANCH=None
TEST=None
Change-Id: I2d7e161c9e12b720ec4925f1acfd1dd8ee6ee5f5
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15641
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360809
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add a device driver to generate the device and required properties
into the SSDT.
This driver uses the ACPI Device Property interface to generate the
required parameters into the _DSD table format expected by the kernel.
This was tested on the reef mainboard to ensure that the SSDT contained
the equivalent parameters that are provided by the current DSDT object.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia809e953932a7e127352a7ef193974d95e511565
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15538
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359310
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15537
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358959
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The function mainboard_get_mac_address() is used to get a MAC address
for a given i210 PCI device. Instead of passing pure numbers for PCI
bus, device and function pass the device pointer to this function. In
this way the function can retrieve the needed values itself as well as
have the pointer to the device tree so that PCI path can be evaluated
there.
BUG=None
BRANCH=None
TEST=None
Change-Id: I2335d995651baa5e23a0448f5f32310dcd394f9b
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15516
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358599
Reviewed-by: Martin Roth <martinroth@chromium.org>
The upstream kernel driver is not using the of-style naming for
sdmode-gpio so remove the maxim prefix, and remove the duplicate
entry for the sdmode-delay value as well.
Also fix the usage of the path variable, since the device path uses
a static variable it can't be assigned that early or it will be
overwritten by later calls.
This results in the following output for the _DSD when tested on
reef mainboard:
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Package (0x02)
{
Package (0x02)
{
"sdmode-gpio",
Package (0x04)
{
_SB.PCI0.HDAS.MAXM,
Zero,
Zero,
Zero
}
},
Package (0x02)
{
"sdmode-delay",
Zero
}
}
})
BUG=None
BRANCH=None
TEST=None
Change-Id: Iab33182a5f64c89151966f5e79f4f7c30840c46f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/15514
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358586
Reviewed-by: Martin Roth <martinroth@chromium.org>
The CR50 device is capable of reporting its firmware version in 4 byte
quantities, but the recently introduced code retrieves the version one
byte at a time.
With this fix the version is retrieved in 4 byte chunks.
BRANCH=none
BUG=none
TEST=the version is still reported properly, as reported by the AP
firmware console log:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: cr50_v1.1.4804-c64cf24
localhost ~ #
Change-Id: I04116881a30001e35e989e51ec1567263f9149a6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356542
Reviewed-by: Andrey Pronin <apronin@chromium.org>
