Add comments on the ops handling in pnp_enable_devices function and the
pnp_info struct.
Also remove the negation in the check if an LDN-specific override is used.
This patch doesn't change the logic though.
Change-Id: I3e80dbce1f29ee3e95e3b1d71c9b8479561d5c1a
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/27384
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
To comply with all relevant bodies throughout the world, SAR settings
take into account the lowest common denominator Tx power settings. This
setup may lead to non-optimal performance when the user location is in a
country that may allow higher power setting. The purpose of Wireless Geo
Delta Settings (WGDS) is to provide offset settings for FCC, Europe,
Japan and Rest of the world. These offsets would be added (by Intel wifi
driver) to the base SAR Tx Power as defined in WRDS and EWRD
BUG=b:65155728
BRANCH=none
TEST=WGDS ACPI table gets created as expected.
Change-Id: I4f602e3f95ff3545db6cc6e428beb9a36abd9296
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/21098
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Will be used on Cavium SoC to delete devicetree entries that aren't
available with the board/configuration.
Change-Id: I7c58a2411206bca62d0e96fa627530e937383ac9
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26693
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
If CPU 0's stack grows to large, it will overflow into CPU 1's stack.
If CPU 0 is handling the interrupt then CPU 1 should be in an idle loop.
When the stack overflow occurs it will override the return pointer for
CPU 1, so when CPU 0 unlocks the SMI lock, CPU 1 will attempt to return
to a random address.
This method is not foolproof. If code allocates some stack variables
that overlap with the canary, and if the variables are never set, then
the canary will not be overwritten, but it will have been skipped. We
could mitigate this by adding a larger canary value if we wanted.
I chose to use the stack bottom pointer value as the canary value
because:
* It will change per CPU stack.
* Doesn't require hard coding a value that must be shared between the
.S and .c.
* Passing the expected canary value as a parameter felt like overkill.
We can explore adding other methods of signaling that a stack overflow
had occurred in a follow up. I limited die() to debug only because
otherwise it would be very hard to track down.
TEST=built on grunt with a small and large stack size. Then verified
that one causes a stack overflow and the other does not.
Stack overflow message:
canary 0x0 != 0xcdeafc00
SMM Handler caused a stack overflow
Change-Id: I0184de7e3bfb84e0f74e1fa6a307633541f55612
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27229
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Add support for parsing and booting FIT payloads.
* Build fit loader code from depthcharge.
* Fix coding style.
* Add Kconfig option to add compiletime support for FIT.
* Add support for initrd.
* Add default compat strings
* Apply optional devicetree fixups using dt_apply_fixups
Starting at this point the CBFS payload/ can be either SELF or FIT.
Tested on Cavium SoC: Parses and loads a Linux kernel 4.16.3.
Tested on Cavium SoC: Parses and loads a Linux kernel 4.15.0.
Tested on Cavium SoC: Parses and loads a Linux kernel 4.1.52.
Change-Id: I0f27b92a5e074966f893399eb401eb97d784850d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25019
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Import from https://chromium.googlesource.com/chromiumos/platform/depthcharge
Coding style and coreboot integration will be done in a separate commit.
Change-Id: Iee56db328d7eeffb0eaf829841243b0b9195c199
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Set the payload argument in selfload, as other (non self) payloads, are
going to set a different argument.
Change-Id: I994f604fc4501e0e3b00165819f796b1b8275d8c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25861
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a method to retrieve a node's phandle.
Useful for board specific devicetree manipulations.
Change-Id: I966151ad7e82fc678ab4f56cf9b5868ef39398e0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Making exceptions for some payload to be loaded near
and under 1 MiB boundary sounds like a legacy 16-bit
x86 BIOS thing we generally do not want under lib/.
Change-Id: I8e8336a03d6f06d8f022c880a8334fe19a777f0a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The file cache_as_ram_ht.inc is used across a variety
of CPUs and northbridges. We need to split it anyway
for future C_ENVIRONMENT_BOOTBLOCK and verstage work.
Split and rename the files, remove code that is globally
implemented in POSTCAR_STAGE framework already.
Change-Id: I2ba67772328fce3d5d1ae34c36aea8dcdcc56b87
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26747
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds PCI ID for Intel TP2 Wi-Fi and adds that to
pci_device_ids in Intel wifi driver.
Change-Id: I51abf615fca6001d564e7cd672cc16f3a0fb8dd6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/26723
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Most, if not all, chipsets have MMIO between 0xfe000000 and 0xff000000.
So don't try to cache more than 16MiB of the ROM. It's also common that
at most 16MiB are memory mapped.
Change-Id: I5dfa2744190a34c56c86e108a8c50dca9d428268
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26567
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As far as I can see this Kconfig option was used wrong ever since it
was added. According to the commit message of 107f72e (Re-declare
CACHE_ROM_SIZE as aligned ROM_SIZE for MTRR), it was only necessary
to prevent overlapping with CAR.
Let's handle the potential overlap in C macros instead and get rid
of that option. Currently, it was only used by most FSP1.0 boards,
and only because the `fsp1_0/Kconfig` set it to CBFS_SIZE (WTF?).
Change-Id: I4d0096f14a9d343c2e646e48175fe2127198a822
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26566
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Have boot_count_read() just return 0 if CONFIG_ELOG_BOOT_COUNT is not
enabled.
BUG=b:79865267
TEST=firmware_EventLog
Change-Id: I70f16226371324dea37b3f36f85c2037e324ef31
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/26526
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make it available early and use it in dev_find_next_pci_device().
Change-Id: I1d0ad07f37ea79dae2b9a592fcccba5e03fd86d5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26294
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Masked ROMs are the silent killers of boot speed on devices without
memory-mapped SPI flash. They often contain awfully slow SPI drivers
(presumably bit-banged) that take hundreds of milliseconds to load our
bootblock, and every extra kilobyte of bootblock size has a hugely
disproportionate impact on boot speed. The coreboot timestamps can never
show that component, but it impacts our users all the same.
This patch tries to alleviate that issue a bit by allowing us to
compress the bootblock with LZ4, which can cut its size down to nearly
half. Of course, masked ROMs usually don't come with decompression
algorithms built in, so we need to introduce a little decompression stub
that can decompress the rest of the bootblock. This is done by creating
a new "decompressor" stage which runs before the bootblock, but includes
the compressed bootblock code in its data section. It needs to be as
small as possible to get a real benefit from this approach, which means
no device drivers, no console output, no exception handling, etc.
Besides the decompression algorithm itself we only include the timer
driver so that we can measure the boot speed impact of decompression. On
ARM and ARM64 systems, we also need to give SoC code a chance to
initialize the MMU, since running decompression without MMU is
prohibitively slow on these architectures.
This feature is implemented for ARM and ARM64 architectures for now,
although most of it is architecture-independent and it should be
relatively simple to port to other platforms where a masked ROM loads
the bootblock into SRAM. It is also supposed to be a clean starting
point from which later optimizations can hopefully cut down the
decompression stub size (currently ~4K on RK3399) a bit more.
NOTE: Bootblock compression is not for everyone. Possible side effects
include trying to run LZ4 on CPUs that come out of reset extremely
underclocked or enabling this too early in SoC bring-up and getting
frustrated trying to find issues in an undebuggable environment. Ask
your SoC vendor if bootblock compression is right for you.
Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds more parameters to bootblock_main_with_timestamp() to
give callers the opportunity to add additional timestamps that were
recorded in the platform-specific initialization phase.
Change-Id: Idf3a0fcf5aee88a33747afc69e055b95bd38750c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26339
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This reverts commit f3d99b6a65.
Reason for revert: We're now doing this through CBFS types instead, so
this shouldn't be needed anymore.
Change-Id: I9e0d5446365f8ecc045615e4ba1a1313080c9479
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26448
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that user can select a specific AP to run
a function.
BUG=b:74436746
BRANCH=none
TEST=Able to run functions over APs with argument.
Change-Id: Iff2f34900ce2a96ef6ff0779b651f25ebfc739ad
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/26034
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Store the type of the loaded program after locating the file and add a
method to retrieve the type.
Will be used to distinguish between SELF and FIT payloads.
Change-Id: Ic226e7e028d722ab9e3c6f7f1c22bde2a1cd8a85
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26028
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch ensures that user can pass a function with given argument
list to execute over APs.
BUG=b:74436746
BRANCH=none
TEST=Able to run functions over APs with argument.
Change-Id: I668b36752f6b21cb99cd1416c385d53e96117213
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This will allow loading of programs that are more than one type,
e.g. ramstage type might now be a stage or payload.
Further, unknown types of 0 are dangerous, make it a real value.
Change-Id: Ieb4eeb7c5934bddd9046ece8326342db0d76363c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/26242
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
This commit adds support for describing USB ports in devicetree.cb.
It allows a USB port location to be described in the tree with
configuration information, and ACPI code to be generated that
provides this information to the OS.
A new scan_usb_bus() is added that will scan bridges for devices so
a tree of ports and hubs can be created.
The device address is computed with a 'port type' and a 'port id'
which is flexible for SOC to handle depending on their specific USB
setup and allows USB2 and USB3 ports to be described separately.
For example a board may have devices on two ports, one with a USB2
device and one with a USB3 device, both of which are connected to an
xHCI controller with a root hub:
xHCI
|
RootHub
| |
USB2[0] USB3[2]
device pci 14.0 on
chip drivers/usb/acpi
register "name" = ""Root Hub""
device usb 0.0 on
chip drivers/usb/acpi
register "name" = ""USB 2.0 Port 0""
device usb 2.0 on end
end
chip drivers/usb/acpi
register "name" = ""USB 3.0 Port 2""
device usb 3.2 on end
end
end
end
end
Change-Id: I64e6eba503cdab49be393465b535e139a8c90ef4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/26169
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The patch series ending in 64049be (lib/bootmem: Add method to walk OS
POV memory tables) expanded the bootmem framework to also keep track of
memory regions that are only relevant while coreboot is still executing,
such as the ramstage code and data. Mixing this into the exsting bootmem
ranges has already caused an issue on CONFIG_RELOCATEABLE_RAMSTAGE
boards, because the ramstage code in CBMEM is marked as BM_RAMSTAGE
which ends up getting translated back to LB_RAM in the OS tables. This
was fixed in 1ecec5f (lib/bootmem: ensure ramstage memory isn't given to
OS) for this specific case, but unfortunately Arm boards can have a
similar problem where their stack space is sometimes located in an SRAM
region that should not be made available as RAM to the OS.
Since both the resources made available to the OS and the regions
reserved for coreboot can be different for each platform, we should find
a generic solution to this rather than trying to deal with each issue
individually. This patch solves the problem by keeping the OS point of
view and the coreboot-specific ranges separate from the start, rather
than cloning it out later. Ranges only relevant to the coreboot view
will never touch the OS-specific layout, to avoid the problem of losing
information about the original memory type of the underlying region that
needs to be restored for the OS view. This both supersedes the
RELOCATABLE_RAMSTAGE fix and resolves the problems on Arm boards.
Change-Id: I7bb018456b58ad9b0cfb0b8da8c26b791b487fbb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds subsystem_id to nhlt structure whose value is
passed on to the endpoint's structure. Its default value is
retained to be NHLT_SSID.
Change-Id: Iad53f27e958f50e02e928cd8fa60d8397ca0eb06
Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Reviewed-on: https://review.coreboot.org/26046
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
barrier_wait_timeout() was not used anywhere in the code. The
remaining two functions, barrier_wait() and release_barrier(), are
not used anywhere but the mp code.
Change-Id: If09991f95306becc68b6008ae6448695fb4a2dca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/26021
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add method to walk memory tables from OS point of view.
The tables don't change when modifiying bootmem entries and doesn't contain
bootmem specific tags.
Change-Id: Iee332a9821d12a7d9a684063b77b0502febd8d7d
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25747
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a method to walk bootmem memory tables and call a function
for each memory range. The tables might not match with OS sight
of view.
Return true if the callback function returned false.
Required for FIT support in coreboot to find a usable RAM region.
Tested on Cavium SoC.
Change-Id: I0004e5ad5fe2289827f370f0d0f9979d3cbd3926
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25583
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Introduce new bootmem tags to allow more fine grained control over buffer
allocation on various platforms. The new tags are:
BM_MEM_RAMSTAGE : Memory where any kind of boot firmware resides and that
should not be touched by bootmem (by example: stack,
TTB, program, ...).
BM_MEM_PAYLOAD : Memory where any kind of payload resides and that should
not be touched by bootmem.
Starting with this commit all bootmem methods will no longer see memory
that is used by coreboot as usable RAM.
Bootmem changes:
* Introduce a weak function to add platform specific memranges.
* Mark memory allocated by bootmem as BM_TAG_PAYLOAD.
* Assert on failures.
* Add _stack and _program as BM_MEM_RAMSTAGE.
ARMv7 and ARMv8 specific changes:
* Add _ttb and _postram_cbfs_cache as BM_MEM_RAMSTAGE.
ARMv7 specific changes:
* Add _ttb_subtables as BM_MEM_RAMSTAGE.
Change-Id: I0c983ce43616147c519a43edee3b61d54eadbb9a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix a function prototype to support PCI on non x86.
The function itself does have the correct argument already.
Change-Id: I564fcfe9b85ed4f841a48fe17a3f5bf80e16560b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There might be certain requirement in user function where user
might not want to pass any timeout value, in those cases
run_ap_work() should consider infinity as timeout and perform
all APs initialization as per specification.
Set expire_us <= 0 to specify an infinite timeout.
BRANCH=none
BUG=b:74436746
TEST=run_ap_work() is running successfully with 0 expire_us.
Change-Id: Iacd67768c8a120f6a01baaa6817468f6b9a3b764
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/25622
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move x86 specific pci_bus_default_ops into arch/x86 folder.
Fixes compilation on platforms that do neither have MMCONF_SUPPORT
nor NO_MMCONF_SUPPORT (for example: all non-x86) but select PCI.
Change-Id: I0991ab00c9a56b23cd012dd2b8b861f9737a9e9c
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25724
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Introduce bootmem custom memory tags and use them instead of reusing
LB_MEM tags.
Use asserts in bootmem_add_range to verify parameters.
Tested with uImage payload on Cavium SoC.
Change-Id: I7be8fa792fc7933ca218ecd43d250d3a9c55caa6
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25633
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
* Adapt to coreboot coding style.
* Use coreboot's endian conversion functions.
* Fix header and header guards.
* Get rid of unused functions.
* Add Kconfig to build it on ramstage.
* Replace size32 with ALIGN_UP and DIV_ROUND_UP.
* Add NULL pointer checks
* Convert constants to defines
Required for Cavium's BDK and uImage FIT support.
Change-Id: I6e6cd9f78fb402bd54d684097326d26eb78d552a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25523
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Import from https://chromium.googlesource.com/chromiumos/platform/depthcharge
Required for general devicetree patching and FIT support.
Coding style and coreboot integration will be done in a separate commit.
Change-Id: Ida75d4786eae38d84bfc71bf53573dafca8eda40
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25632
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
For broken devices that spuriously advertise ASPM, make it possible to
decide ASPM activation in the device driver.
Change-Id: I491aa32a3ec954be87a474478609f0f3971d0fdf
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/25617
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When employing PAGING_IN_CACHE_AS_RAM more areas need to be
mapped in at runtime. Therefore, paging_identity_map_addr() is
added to support adding identity mappings. Because there are a
fixed amount of pages in cache-as-ram paging only the existing
paging structures can be used. As such that's a limitation on
what regions and length one can map. Using util/x86/x86_page_tables.go
to generate page tables will always populate all the page directory
pages. Therefore, 2MiB mappings are easy to map in.
BUG=b:72728953
Change-Id: Ibe33aa12972ff678d2e9b80874529380b4ce9fd7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25718
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In some cases it may be useful to be able to bitbang a UART, such as
during early bring-up when a driver for the actual controller isn't
available yet. On some platforms we may even want to use this
permanently, such as on the SDM845 where the hardware UART controller
needs to have firmware loaded and is thus unavailable for most of the
bootblock.
This patch adds some helper code that makes it easy to implement this on
a platform, you just have to pass it a function to control the Tx pin
state and it will do the rest. It relies on the mono_time API and is
thus bound to microsecond timing granularity, but that seems to be
barely good enough for 115200 baud if the bit times are calculated
carefully.
Change-Id: If7dcecc7b8a95ec15f456efd2ec1f1e0dde239b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Processors, such as glk, need to have paging enabled while
in cache-as-ram mode because the front end is agressive about
fetching lines into the L1I cache. If the line is dirty and in
the L1D then it writes it back to "memory". However, in this case
there is no backing store so the cache-as-ram data that was written
back transforms to all 0xff's when read back in causing corruption.
In order to mitigate the failure add x86 architecture support for
enabling paging while in cache-as-ram mode. A Kconfig variable,
NUM_CAR_PAGE_TABLE_PAGES, determines the number of pages to carve
out for page tables within the cache-as-ram region. Additionally,
the page directory pointer table is also carved out of cache-as-ram.
Both areas are allocated from the persist-across-stages region
of cache-as-ram so all stages utilizing cache-as-ram don't corrupt
the page tables.
The two paging-related areas are loaded by calling
paging_enable_for_car() with the names of cbfs files to load the
initial paging structures from.
BUG=b:72728953
Change-Id: I7ea6e3e7be94a0ef9fd3205ce848e539bfbdcb6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
DDR4 reserves 20 bytes for part number without termination. Therefor
coreboot buffer for part number has to be increased to 21 bytes, to
account termination.
BUG=b:77943312
TEST=Build kahlee.
Change-Id: I57aa8e06d907a1e6b11ce88f612a0d6c14b7c65b
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/25650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add ENV_CACHE_AS_RAM to indicate to compilation units if cache-as-ram
is employed for that particular stage.
BUG=b:72728953
Change-Id: I06dfa7afe2d967229549090d5aa95455687b0bb9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25716
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Julius brought up confusion about the current spi api in [1]. In order
alleviate the confusion stemming from supporting x86 spi flash
controllers:
- Remove spi_xfer_two_vectors() which was fusing transactions to
accomodate the limitations of the spi controllers themselves.
- Add spi_flash_vector_helper() for the x86 spi flash controllers to
utilize in validating driver/controller current assumptions.
- Remove the xfer() callback in the x86 spi flash drivers which
will trigger an error as these controllers can't support the api.
[1] https://mail.coreboot.org/pipermail/coreboot/2018-April/086561.html
Change-Id: Id88adc6ad5234c29a739d43521c5f344bb7d3217
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25745
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Add paging_set_default_pat() which sets up the PAT MSR according
to util/x86/x86_page_tables.go. Using page attribute types require
a matching of the PAT values with the page table entries. This function
is just providing the default PAT MSR value to match against the
utility.
BUG=b:72728953
Change-Id: I7ed34a3565647ffc359ff102d3f6a59fbc93cc22
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25715
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Add the following functions for use outside of the paging module:
void paging_enable_pae_cr3(uintptr_t cr3);
void paging_enable_pae(void);
void paging_disable_pae(void);
The functions just enable and/or disable paging along with PAE.
Disassembly shows equivalent output for both versions.
BUG=b:72728953
Change-Id: I9665e7ec4795a5f52889791f73cf98a8f4def827
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25714
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
The EFER and PAT MSRs are x86 architecturally defined. Therefore,
move the macro defintions to msr.h. Add 'paging' prefix to the
PAT and NXE pae/paging functions to namespace things a little better.
BUG=b:72728953
Change-Id: I1ab2c4ff827e19d5ba4e3b6eaedb3fee6aaef14d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Make sure to define __SIMPLE_DEVICE__ on x86 only, as other platforms
currently doesn't have support for it.
Fixes static.c devicetree compilation on non x86.
Change-Id: I75fb038681a8edf119415705af5da9f999fd8225
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25721
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Move inline function where they belong to. Fixes compilation
on non x86 platforms.
Change-Id: Ia05391c43b8d501bd68df5654bcfb587f8786f71
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25720
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generalize cbfs_boot_load_struct() by passing in CBFS type
Change-Id: I6e5f845cb4ce5b00f01a39619919f85e39028f19
Signed-off-by: T Michael Turney <mturney@codeaurora.org>
Reviewed-on: https://review.coreboot.org/25648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
- Fix offsets for supported CAS latencies
- Add support for reading CWL and CMD rate from the profile
Change-Id: Ie4f545ed1df92c146be02f56fea0ca9037478649
Signed-off-by: Dan Elkouby <streetwalkermc@gmail.com>
Reviewed-on: https://review.coreboot.org/25663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In https://review.coreboot.org/25383 people were confused about the
ordering of bootmem calls w.r.t. when entries are exposed to the OS. To
alleviate this add a notion of bootmem being initialized. In addition to
that, only mark bootmem initialized when bootmem_write_memory_table() is
called. Any other calls to bootmem before that will report an error on
the console.
Change-Id: I5bc31f555038ccabb82d902c54f95858679b1695
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
dimm_info.serial had a strange contract. The SPD spec defines a 4 byte
serial number. dimm_info.serial required a 4 character ascii string with
a null terminator.
This change makes the serial field so it matches the SPD spec.
smbios.c will then translate the byte array into hex and set it on the
smbios table.
There were only two callers that set the serial number:
* haswell/raminit.c: already does a memcpy(serial, spd->serial, 4), so
it already matches the new contract.
* amd_late_init.c: Previously copied the last 4 characters. Requires
decoding the serial number into a byte array.
google/cyan/spd/spd.c: This could be updated to pass the serial number,
but it uses a hard coded spd.bin.
Testing this on grunt, dmidecode now shows the full serial number:
Serial Number: 00000000
BUG=b:65403853
TEST=tested on grunt
Change-Id: Ifc58ad9ea4cdd2abe06a170a39b1f32680e7b299
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/25343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new method to clone an existing memrange with all of its entries.
Required for new bootmem type LB_MEM_RAM_DONT_OVERLAP.
Change-Id: I64b27bf2611ca310385ef680f030a3e4aa0c2680
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25582
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
AMD AGESA returns DIMM info in SMBIOS format. dimm_info expects the data
in SPD format. These methods will be used to update amd_late_init.c so
it sets the correct values.
BUG=b:65403853
TEST=Built and booted grunt. Methods are not called in this commit. So
they were tested with the later commit by verifying the output of
dmidecode.
Change-Id: Id9fa98e9aad83dfd0a86f45e18b3c312665dce9b
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/25412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
DDR2 DIMMs are uniquely defined by SPD byte 64 till 72 and 93 till
98. Compute a crc16 over that data to provide a solid way to check
DIMM identify.
Reuse the crc16 function from ddr3.c to do this.
Change-Id: I3c0c42786197f9b4eb3e42261c10ff5e4266120f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23345
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
It's a standard function.
Change-Id: I039cce2dfc4e168804eb7d12b76a29af712ac7a1
Signed-off-by: David Hendricks <dhendricks@fb.com>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/23616
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copy strrchr from libpayload.
To be used by Cavium's BDK or FDT parsers.
Change-Id: Iab7981c25113ed16f1b8130de4935d30c29d2fa5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25447
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Sometimes when bringing up a new board it can take a while until you
have all the peripheral drivers ready. For those cases it is nice to be
able to bitbang certain protocols so that you can already get further in
the boot flow while those drivers are still being worked on. We already
have this support for I2C, but it would be nice to have something for
SPI as well, since without SPI you're not going to boot very far.
This patch adds a couple of helper functions that platforms can use to
implement bit-banging SPI with minimal effort. It also adds a proof of
concept implementation using the RK3399.
Change-Id: Ie3551f51cc9a9f8bf3a47fd5cea6d9c064da8a62
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/25394
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds the support for KBL-S MCH and Z270, H270, B250 and
Q250 PCH chips.
BUG=None
BRANCH=None
TEST=Boot with KBL-S CPU and B250/H270 PCHs.
Change-Id: If03abb215f225d648505e05274e2f08ff02cebdc
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.com>
Reviewed-on: https://review.coreboot.org/25305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Naresh Solanki <naresh.solanki@intel.com>
Add more information on baseboard as described in SMBIOS Reference
Specification 3.1.1.
Change-Id: I9fe1c4fe70c66f8a7fcc75b93672421ae808bf1b
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23842
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The SMBus PCI device ID for Stoney wasn't updated when the code was
pulled over from hudson. This means that the IOAPIC wasn't being
initialized in coreboot.
BUG=b:74070580
TEST=Boot Grunt, see IOAPIC init messages in console.
Change-Id: Ida5d3f3592488694681300d79444c1e26fff6a1a
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/24930
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some DIMMs have invalid strings when it comes to device part number
(bytes 0x149-0x15c). From DDR4 SPD specs it should be ASCIIZ with unused
space filled with white spaces (ASCII 0x20). Byte 20 should be 0 (ASCIIZ),
all others should be ASCII.
Create a test that detects invalid strings and replace invalid
characters with *. If a replacement was made the output string then must
be <Invalid (replaced string)>.
BUG=b:73122207
TEST=Build, boot and record serial output for kahlee while injecting
different strings to dmi17->PartNumber. Use code to examine SMBIOS,
while testing different valid and invalid strings.
Remove string injection before committing.
Change-Id: Iead2a4cb14ff28d263d7214111b637e62ebd2921
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/23844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
This change adds a config option to allow mainboard to override
the console loglevel. When the option is set, the platform has
to define the function get_console_loglevel returning a valid
loglevel value.
This allows a mainboard to sample a GPIO to switch the loglevel
value between different environments (qualification vs production)
without re-flashing.
Change-Id: Id6cc72b8fe5c4c50a6f83ce80e6440b078eec6e2
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23712
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
In order for ddr2.h and ddr3.h to be included in the same file it
cannot have conflicting definitions, therefore rename a few things and
move some things to a common header.
Change-Id: I6056148872076048e055f1d20a60ac31afd7cde6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
The rationale is to allow the mainboard to override the default
baudrate for instance by sampling GPIOs at boot.
A new configuration option is available for mainboards to select
this behaviour. It will then have to define the function
get_uart_baudrate to return the computed baudrate.
Change-Id: I970ee788bf90b9e1a8c6ccdc5eee8029d9af0ecc
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23713
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
AMD's fixed MTRRs have RdDram and WrDram bits that route memory
accesses to DRAM vs. MMIO. These are typically hidden for normal
operation by clearing SYS_CFG[19] (MtrrFixDramModEn). According to
BKDGs and AMD64 Programmer's Manual vol 2, this bit is clear at
reset, should be set for configuration during POST, then cleared for
normal operation.
Attempting to modify the RdDram and WrDram settings without unhiding
them causes a General Protection Fault. Add functions to enable and
disable MtrrFixDramModEn. Unhide/hide as necessary when copying or
writing the fixed MTRRs.
Finally, modify sipi_vector.S to enable the bits prior to writing
the fixed MTRRs and disable when complete.
This functionality is compiled out on non-AMD platforms.
BUG=b:68019051
TEST=Boot Kahlee, check steps with HDT
Change-Id: Ie195131ff752400eb886dfccc39b314b4fa6b3f3
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23722
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Leverage the stage_cache mechanism to store a non-specific type
of data. This is not interesting when the location for the cache
is in cbmem. However it will be more useful when an external
location is used, e.g. when the cache is in TSEG, locked from user
modification.
Change-Id: Iaf0b25ebe14c176bbd24fc8942f902f627ca8e6f
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23518
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Write _ROM method and store PCI Option ROM in CBMEM.
Allows an EFI compatible OS to retrieve the Option ROM without the need
to access the PCI BAR. As the Option ROM is no longer present in the
legacy VGA area it's required for mobile platforms. On hybrid devices,
like Lenovo Thinkpads supporting NVIDIA Optimus it's the only way to
retrieve the Option ROM, even with legacy BIOS, as there's no PCI BAR to
map.
Tested on:
* Lenovo T530
* Linux Kernel 4.13.7
* nouveau
Change-Id: I548b730fb64833083cc05af5b21dd6959804224b
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/20548
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
spi_crop_chunk() currently supports deducting the command length
when determining maximum payload size in a transaction. Add support
for deducting just the opcode part of the command by replacing
deduct_cmd_len field to generic flags field. The two enums supported
drive the logic within spi_crop_chunk():
SPI_CNTRLR_DEDUCT_CMD_LEN
SPI_CNTRLR_DEDUCT_OPCODE_LEN
All existing users of deduct_cmd_len were converted to using the
flags field.
BUG=b:65485690
Change-Id: I771fba684f0ed76ffdc8573aa10f775070edc691
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23491
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for a mmio resource in the devicetree to allow
memory-mapped IO addresses to be assigned to given values.
AMD platforms perform a significant amount of configuration through
these MMIO addresses, including I2C bus configuration.
BUG=b:72121803
Change-Id: I5608721c22c1b229f527815b5f17fff3a080c3c8
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23319
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Rename the device ID macros as per the skylake PCH H external design
specification.
Change-Id: I4e80d41380dc1973d02bc69ac32aad5c4741a976
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/23381
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If one wants to implement both i2c_bus.h and i2c_simple.h APIs
the compilation unit needs to be guarded or coordinated carefully
with different compilation units. Instead, name the i2c_bus
functions with _dev such that it indicates that they operate on
struct device. One other change to allow i2c_bus.h to be built in
non-ramstage environments is to ensure DEVTREE_CONST is used for
the dev field in struct bus.
BUG=b:72121803
Change-Id: I267e27e62c95013e8ff8b0728dbe9e7b523de453
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
* Move code from src/lib and src/include into src/security/tpm
* Split TPM TSS 1.2 and 2.0
* Fix header includes
* Add a new directory structure with kconfig and makefile includes
Change-Id: Id15a9aa6bd367560318dfcfd450bf5626ea0ec2b
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/22103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is common HDA code in soc/intel/common that provides generic
HDA support functions, but it does not provide a driver.
This change adds a common block driver for HDA that provides a
ramstage driver for SOCs that need to initialize an HDA codec.
This was tested on a board with an HDA codec to ensure that it
properly detected it and ran the codec init steps.
Change-Id: I41b4c54d3c81e1f09810cfaf934ffacafca1cf38
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/23187
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's nothing intel-specific about the current mrc_cache support.
It's logic manages saving non-volatile areas into the boot media.
Therefore, expose it to the rest of the system for any and all to
use.
BUG=b:69614064
Change-Id: I3b331c82a102f88912a3e10507a70207fb20aecc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22901
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Provide a spi controller specific protection callback to take
advantage of special spi flash controllers that have internal
protection registers built into the implementation. It's an
optional callback for spi controllers.
BUG=b:69614064
Change-Id: Ie50a6ce3bbda32620a25dd26fda1af944940bf28
Signed-off-by: Aaron Durbn <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Felix Held