This is already handled as a separate case in the code below, so there's
no need for this assert any more.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I7511ec5683a924dc289faa2b9fabd0e8714d291e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Use a define instead of magic numbers.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c6d17bd78a0e207f9130102b43ba78aa55ce377
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79046
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Previously acpigen_pop_len always wrote a 3 byte PkgLength to the 3
bytes reserved by acpigen_write_len_f. After this patch acpigen_pop_len
encodes PkgLength in 1-3 bytes depending on the PkgLength. When less
than the 3 bytes that were previously reserved in the corresponding
acpigen_write_len_f call are needed for PkgLength, the payload data will
be moved back by the number of reserved bytes that aren't needed for the
PkgLength.
This fixes the problem that the Windows AML parser doesn't like a 3 byte
PkgLength being used for the size of the buffer containing UTF-16
strings when the length could be encoded in a single PkgLength byte. In
that case, Windows previously ignored the whole SSDT containing this
larger than necessary PkgLength encoding. It should however be noted
that the ACPI 6.4 spec doesn't specify if it's required to always use
the most compact possible encoding of the PkgLength or not. Since iasl
generates the shortest possible PkgLength encoding, it's also a good
idea to make coreboot's acpigen do the same although it's not required
by the specification.
With this patch applied, Windows still boots on Mandolin and the time it
takes to write the tables doesn't change. To measure the times, the log
level in bs_sample_time was increased to BIOS_CRIT and the console log
level was increased to BIOS_CRIT too to only get those times as output.
BS: BS_WRITE_TABLES run times (exec / console): 8 / 0 ms
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib897b08a05a7cdc52902d51364246c260ea1f206
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79002
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jérémy Compostella <jeremy.compostella@intel.com>
This patch adds asl code for MMIO device like I2C, UART, GPIO etc.
Change-Id: Ic5bc2cc0141e9da7e2c6ed7691188d7c94b6b1e3
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>t show
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78895
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Some functions in the headers for sc7180 and sc7280 specified the
int as their return type when they should have used enum cb_err.
Found while testing GCC 13.2.0
Change-Id: I41331fe708a396f7f2f40359e8ba03c8a46a4d4b
Signed-off-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79015
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Julius Werner <jwerner@chromium.org>
With the update to GCC 13 a new warning about subtracting numbers from
arrays appears.
src/arch/arm64/armv8/mmu.c:296:9: error: array subscript -1 is outside array bounds of 'u8[]' {aka 'unsigned char[]'} [-Werror=array-bounds=]
Change-Id: I4757ca2e7ad3f969d7416041ea40c3e9866cdf49
Signed-off-by: Zebreus <lennarteichhorn@googlemail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79014
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The THRM and SATA PCI devices do not currently have any ACPI devices
defined, so drop them from soc_acpi_name() so they do not end up in
the LPI constraint list. This eliminates the following errors
under Linux:
AE_NOT_FOUND: _SB_.PCI0.THRM
AE_NOT_FOUND: _SB_.PCI0.SATA
TEST= build/boot google/hatch (jinlon) and verify no ACPI errors.
Change-Id: I3827b152644e2eaecc1ad288d441d2dad4d76ccb
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79013
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), no boards use this header anymore and it
no longer offers original content.
Adjust northbridge code #includes as needed and drop it.
Change-Id: I2785e920bd6188dbfc1a6157351083ec4a2526d0
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78785
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
After commit 940fe080bf (mb/apple/macbookair4_2: Correctly implement
SPD mapping the Haswell way), this file is obsolete
and can be removed.
Change-Id: I5afe6809c7097ab8529a3c1ec7befbd0d6f01c5f
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
With commit adaeb11021 (nb/intel/sandybridge: Clean up post Haswell SPD mapping API migration), raminit_native.h now only includes 4
other headers and offers no original content. Based on the idea that
all source files should include what they use directly, drop it in
favor of sandybridge.h (which it already includes anyway) and types.h
(replacing stdint.h because it also uses boolean constructs).
Board appears to not use anything sb/intel/bd82x6x/pch.h provides.
And the board still builds after dropping it.
Change-Id: I1b201fe4dd29bac5feb08f372d1e36353eac161d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78783
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All of these signals have net names, but are actually unstuffed, so we
have to set them to NC.
BUG=b:300690448
BRANCH=None
TEST=emerge-brox coreboot
Change-Id: I27d8b7cd02aefb49a2dc031a30eb0d1e8aa9faa9
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Report smbios_cpu_get_voltage() on Sandy Bridge as well.
Change-Id: I13ea930a58eaedc24d69fa3790f1f2a151558a80
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78432
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: I866250602701e7e83a695d346f4b404b1bbae6d5
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: I4f2c4f4a576ea2fd2ccb7a7e6b52cf258bac5f84
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79043
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ie25c56f48648733095ab9d2a565c842b2f90efb2
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79041
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ic25d112a95903e77b58bda70bbcc3f08df383395
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79035
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: If4f89fb81664474e03ab0ade76cfbd617127127e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79040
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: I413a3630bda841ae9ed6c4a584d2250a81c28308
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ic4043828baf43d14f7f2060fa3946e3a9e2008fc
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79038
Reviewed-by: Eric Lai <ericllai@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The comments related to the PCI devices are superfluous since the
reference names from the chipset devicetree are used. So remove the
comments and also the devices which are turned off, or in general have
an equal state compared to the configuration in chipset devicetree.
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ic45446b03a3c571837fc1c41f55d60bdf2a25a7e
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ib1adeaf4745804dfc91f99fb4e4491b68631202c
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
- Disable unconnected PCH PCIe ports 1 + 3.
- Add smbios_slot_desc to WLAN PCIe port
- Add comment for PCIe port 7 that might have a
XHCI controller connected (some variants only).
Test: Lenovo X220 still boots and all devices are still working
fine. The WLAN slot is shown in dmidecode -t 9.
Change-Id: I3fdfbb7ad30e2ff8a289d9055eaef0557475fdff
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: I6ba850c783999d06c73137ed77d32fc108a20347
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79034
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: Ib6edae61fb904143c3b3994df812524a258fa9f3
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: I9f92246da4a500e85c878d865d621033f6b35f1b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78593
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <ericllai@google.com>
With migration to Haswell SPD mapping interface complete:
1. Remove weak stubs meant to ensure smooth transition and
internalizes mainboard_get_spd() within raminit.c.
2. Remove post-mainboard SPD data sanitization code in raminit_mrc.c,
now that it fills its own SPD data.
3. Remove old prototypes from raminit_native.h
4a. Drops raminit_native.h from raminit.c, as individual headers
therein are already included.
4b. Drop another header from raminit.c IWYU identified as unneeded.
asus/p8z77-m still builds afterwards.
(sandybridge to receive a full IWYU cleanup later.)
Change-Id: Ie073c1386cd0a645069f0e1416263b4fa359b74b
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76991
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Boards without HAVE_SPD_IN_CBFS: Move SPD mapping into devicetree.
Boards with HAVE_SPD_IN_CBFS: Convert to Haswell-style SPD mapping.
Change-Id: Id6ac0a36b2fc0b9686f6e875dd020ae8dba72a72
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76967
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
While converting this board to provide SPD info using the Haswell API,
it was discovered that its SPD setup was not correct to begin with.
For a board that only has soldered down memory with SPD data in CBFS,
it didn't enable HAVE_SPD_IN_CBFS in Kconfig. It also duplicated one
set of SPD data with deliberate gaps in between. It worked its dark
magic within mainboard_get_spd(), which is going away as a callback.
Add HAVE_SPD_IN_CBFS to mainboard Kconfig, recreate the one set of SPD
data as a hex dump same as other boards, and hook everything back up
with Haswell-style mb_get_spd_map().
Recreated SPD data was extracted from abuild-built binary and manually
verified for correctness against existing spd.bin (which will be
removed in a follow-up).
Change-Id: I906c49f6d1949f830828530edc0298b1b22ec04d
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76995
Reviewed-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Changes both MRC and native raminit code path to get SPD mapping
from one place.
Boards with all memory socketed specify their mappings in a
devicetree setting introduced in commit 5709e03613
("nb/intel/sandybridge: Migrate MRC settings to devicetree") back in
May 2019 but remains unused as of this patch. This setting
will now hold raw SMBus addresses, and MRC raminit gets code to
translate them into a representation MRC expects.
Boards with soldered down memory (specifically with HAVE_SPD_IN_CBFS
in their board Kconfig), with or without socketed memory, specify
their layouts in mb_get_spd_map() as used by Haswell boards, where
they access hardware GPIO straps to select which SPD data to use.
This harmonizes the way boards specify their SPD layouts across
Haswell/SNB/IVB boards whether using MRC or native raminit. Going
forward they only need to specify the layout in one place. (Going
forward the devicetree setting should be backported to Haswell,
once we get native raminit working there.)
With this, northbridge code is now fully responsible for loading
all SPD data, be it from CBFS or SMBus.
To avoid breakage, transition will happen in stages:
1. This patch gets all the code in, and implements weak stubs that
maintain existing code and data flow (i.e. mainboards still populate
final SPD layout data). At this point devicetree already uses new
representation, but is still unused meaning no breakage.
2. Follow-up patch(es) remove mainboard_get_spd() from mainboards, and
replace it with mb_get_spd_map() or devicetree values (as appropriate)
with converted SPD info. The "weak" mainboard_get_spd() with new logic
takes over. Boards go Haswell Style at this point. Boards with MRC
raminit also lose code to fill in SPD data, allowing new data to take
hold.
3. Clean-up patch removes the weak functions and public prototypes re
mainboard_get_spd(), making it internal to northbridge. Changeover is
complete.
Change-Id: I1a75279d981e46505930a9ce1aae894ccc4e1f24
Signed-off-by: Keith Hui <buurin@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76965
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use the references from the chipset devicetree as this makes the
comments superfluous and remove devices which are turned off.
Change-Id: I0f069f02e4f0957cbff05d1bc9aa499fb51b6a02
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78574
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This patch uses AMD SoC common code for MCA and adds MCA bank
information as per Genoa Processor Programming Reference (PPR)
version 0.25 (#55901) and uses AMD SoC common code.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: If728d803d600f7e86507cd1b35b40022bf4d379e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76524
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
All CPUs properly come out of reset and relocate SMM.
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Change-Id: I8c2d976addacd5a2ba70eb629510128853b9f847
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76523
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Default value of HEAP_SIZE is 0x100000, since genoa has a lot of
CPU increase the HEAP_SIZE to 0x200000
Change-Id: Idd707200fe72730849267cd3cafc40e44f1f8c5d
Signed-off-by: Varshit Pandya <pandyavarshit@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78894
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
In vboot_get_context(), vb2api_reinit() is called to restore the vboot
context from the previous stage. We use assert() for the return value of
vb2api_reinit() because there shouldn't be runtime errors, except for
one edge case: vb2_shared_data struct version mismatch. More precisely,
when RW firmware's VB2_SHARED_DATA_VERSION_MINOR is greater than RO's,
vb2api_reinit() will return VB2_ERROR_SHARED_DATA_VERSION.
To avoid using an invalid vb2_context pointer (when FATAL_ASSERTS is
disabled), change assert() to die() on vb2api_reinit() failure. For the
vb2api_init() case the assertion is unchanged because there shouldn't be
any runtime error for that.
Also move the vb2api_init() call outside the assert() argument, as
assert() may be a no-op macro depending on the implementation.
Change-Id: I4ff5ef1202bba2384c71634ec5ba12db1b784607
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78808
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The symbol VBT_DATA_SIZE_KB was removed in commit 8bde652241 -
"drivers/intel/gma/opregion: Use CBFS cache to load VBT" CB:77886,
however that patch only removed the Kconfig option from the Intel
chipsets, leaving it unused in the mainboards.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ia29d8d6ec17b172e662ff591849f1668d65f1ff9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78967
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Eric Lai <ericllai@google.com>
This is a fixup to CB:78914 which inadvertently broke the RK3288 SoC.
Unfortunately we can only accommodate very little PRERAM_CBFS_CACHE in
the tiny SRAM for that chip, so we would not be able to map an entire
FMAP. Solve this problem for now by mapping less space when CBFS
verification is disabled, and disallowing CBFS verification on that SoC.
Change-Id: I2e419d157dc26bb70a6dd62e44dc6607e51cf791
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Proposed in the comment of commit 29030d0f3d
("drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume"),
during sanitize_cmos(), only reset CMOS range covered by checksum and
the checksum itself from the file cmos.default in CBFS, in order to
prevent other runtime data in CMOS (e.g. the DRAM training data on
GM45 platforms for s3 resume) being erased.
Tested: cherry-pick this commit before commit 44a48ce7a4 ("Kconfig:
Bring HEAP_SIZE to a common, large value"), which is already
before my commit 29030d0f3d , Thinkpad X200 with
CONFIG(STATIC_OPTION_TABLE) can resume from s3 again,
indicating that DRAM training data are no longer erased.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Co-authored-by: Jonathon Hall <jonathon.hall@puri.sm>
Change-Id: I872bf5f41422bc3424cd8631e932aaae2ae82f7a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78906
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
init() was always followed by open() and after successful initialization
we only need send-receive function which is now returned by tis_probe()
on success, thus further reducing number of functions to export from
drivers.
This also removes check for opening TIS twice that seems to have no
value.
Change-Id: I52ad8d69d50d449f031c36b15bf70ef07986946c
Ticket: https://ticket.coreboot.org/issues/433
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76954
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a few new files to romstage, that will be needed in
follow-up patches.
Change-Id: I2ba84e0becee883b5becf12e51f40734cad83d7d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68839
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Updating from commit id d81517e:
2023-09-28 14:13:56 -0600 - (Improper bit field offset calculation)
to commit id 0411c75:
2023-11-10 23:59:34 +0000 - (Minor changes to fix issues compiling with clang)
This brings in 1 new commits:
0411c75 Minor changes to fix issues compiling with clang
Change-Id: Ib3adfd7bccd45dfd76ede462677dcfb294baa15d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79009
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
To see which Kconfig symbols are actually used, and to verify that
they're used correctly, kconfig_lint scans the C code. It gives an error
if it sees a CONFIG(symbol) where the symbol doesn't exist.
This creates a problem when a C preprocessor macro is created to match
multiple Kconfig symbols. The simple solution here is to just ignore
those C preprocessor macro definitions as beyond the scope of this
linter.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I5a20e8bb5a3e19e380802cba712d6dd3ff2f4dc0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/78681
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When a package length needs to be written, we used to always
write three bytes for it, even when the length would fit into
one or two bytes. To allow such compact package lengths, we
have to move the written buffer data in case the length is
smaller. This makes tracking the start of nested buffers
harder, as they may be moved entirely later when a package
length is written. So instead of tracking start addresses in
test_acpigen_nested_ifs(), let's work with the generated AML
alone. In this lucky case, we can simply search for the `if`
operations.
Change-Id: Id8557dd5d1be3878713ee0b6106c3e0975665e97
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/79008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Felix Held