coreboot-gerrit April 2024

coreboot-gerrit@coreboot.org

1 participants
3292 discussions

[XS] Change in coreboot[main]: drivers/intel/mipi_camera: Add CSI2 Data Stream Interface GUID
by CoolStar (Code Review) 30 Apr '24

30 Apr '24

Attention is currently required from: CoolStar, Felix Singer, Matt Delco, Sugnan Prabhu S. Hello Matt DeVillier, Matt Delco, Sugnan Prabhu S, build bot (Jenkins), I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/82068?usp=email to look at the new patch set (#3). Change subject: drivers/intel/mipi_camera: Add CSI2 Data Stream Interface GUID ...................................................................... drivers/intel/mipi_camera: Add … [View More]

1 0

[M] Change in coreboot[main]: arch/x86: Enable long mode entry into payload for x86_64 support
by Julius Werner (Code Review) 30 Apr '24

30 Apr '24

Attention is currently required from: Arthur Heymans, David Hendricks, Jérémy Compostella, Kapil Porwal, Nico Huber, Patrick Rudolph, Subrata Banik, Werner Zeh. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/81960?usp=email ) Change subject: arch/x86: Enable long mode entry into payload for x86_64 support ...................................................................... Patch Set 14: (2 comments) Patchset: PS14: > > I can … [View More]understand Subrata's rational to transfer control to the payload in 64 bit seamlessly withou […] I think the answer is "no"? I don't think there's really a way to do that without getting very crazy (e.g. running the payload under VMX). I strongly doubt that there's a need for this that would justify going to such lengths... when people care about running older payloads under new coreboot I think they usually care about doing it on the same old platform that payload was originally developed for. If you're developing for an entirely new platform, I think you can recompile your payload once. PS14: > And you are in favor of a new CBFS type (not a new segment type), is that correct? Yes, I think doing that (and not having multiple entry points) would be the cleanest and easiest solution. > Dual entry aside, do we already have code in coreboot that considers archi- tecture-specific types or would we have to add code? It's not directly architecture-specific, but we do have the precedent of CBFS_TYPE_FIT, which is a different payload format (different from SELF) that is only used on Arm (and I think maybe also RISC-V now?). So I think treating "SELF but in 64-bit" as another case like that and adding CBFS_TYPE_SELF64 would be consistent. The nice part about this is that `payload_load()` already extracts the CBFS type and stores it in `struct prog` anyway, so all the code to get this type and pipe it through to where it needs to go is already in place. All we'd need to do to support it is to add another case label to the same code path for running `selfload()` that already exists in `payload_load()`, and then check `prog->cbfs_type` in `arch_prog_run()` to do a different hand-off. Any of the other solutions about using CBFS attributes or SELF segments would instead require adding extra piping to `struct prog` (in addition to the other concerns mentioned previously). > I don't want to repeat my whole email here, my basic thought was how we could do it with minimal (or no) additional complexity in coreboot. And preferably the least ifs in coreboot and payload build systems. I think the solution I'm suggesting would be pretty much that, I don't think you can make it any simpler. > If we do the long-mode handover now before X86S, we have to answer more questions, e.g. What should a 64-bit coreboot on AMD64 do when it encounters a 32-bit payload? I think in order to keep the default configuration compatible with the way people who've been building coreboot for X86_64 used it before, we need to support that (unless everyone here says that nobody has been using it yet and nobody cares?). So we keep the current code that switches back down to protected mode, and decide whether to use it based on the CBFS type. I would suggest to also add a (default-off) Kconfig to disable building in that code, so that platforms which know they'll never need it can save on code size (and then they'll just `die()` if they encounter the wrong payload type). But that's also something that could be discussed and added later and doesn't need to be part of the immediate decision here. -- To view, visit https://review.coreboot.org/c/coreboot/+/81960?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: Ic5e6f0af11c05e8b075b8c20880c012747a1df9b Gerrit-Change-Number: 81960 Gerrit-PatchSet: 14 Gerrit-Owner: Subrata Banik <subratabanik(a)google.com> Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Reviewer: Kapil Porwal <kapilporwal(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-CC: David Hendricks <david.hendricks(a)gmail.com> Gerrit-CC: Matt DeVillier <matt.devillier(a)gmail.com> Gerrit-CC: Nico Huber <nico.h(a)gmx.de> Gerrit-CC: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-CC: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-Attention: Nico Huber <nico.h(a)gmx.de> Gerrit-Attention: Subrata Banik <subratabanik(a)google.com> Gerrit-Attention: Patrick Rudolph <patrick.rudolph(a)9elements.com> Gerrit-Attention: Jérémy Compostella <jeremy.compostella(a)intel.com> Gerrit-Attention: David Hendricks <david.hendricks(a)gmail.com> Gerrit-Attention: Kapil Porwal <kapilporwal(a)google.com> Gerrit-Attention: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Attention: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-Comment-Date: Tue, 30 Apr 2024 19:47:51 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: Nico Huber <nico.h(a)gmx.de> Comment-In-Reply-To: David Hendricks <david.hendricks(a)gmail.com> Comment-In-Reply-To: Julius Werner <jwerner(a)chromium.org> Comment-In-Reply-To: Werner Zeh <werner.zeh(a)siemens.com> Gerrit-MessageType: comment [View Less]

1 0

[XS] Change in coreboot[main]: soc/amd/phoenix/include/platform_descriptor: remove TODO
by Felix Held (Code Review) 30 Apr '24

30 Apr '24

Attention is currently required from: Fred Reitberger, Jason Glenesk, Matt DeVillier. Hello Fred Reitberger, Jason Glenesk, Matt DeVillier, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/82150?usp=email to look at the new patch set (#2). Change subject: soc/amd/phoenix/include/platform_descriptor: remove TODO ...................................................................... soc/amd/phoenix/include/platform_descriptor: remove TODO … [View More]

1 0

[XS] Change in coreboot[main]: soc/amd/phoenix/include/platform_escriptor: remove TODO
by Felix Held (Code Review) 30 Apr '24

30 Apr '24

Felix Held has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/82150?usp=email ) Change subject: soc/amd/phoenix/include/platform_escriptor: remove TODO ...................................................................... soc/amd/phoenix/include/platform_escriptor: remove TODO There's nothing in this header file that needs to be updated for the Phoenix SoC, so remove the 'Update for Phoenix' TODO. Signed-off-by: Felix Held <felix-coreboot(a)felixheld.de> … [View More]

1 0

[XS] Change in coreboot[main]: drivers/intel/fsp2_0: Release bmp_logo during READY_TO_BOOT stage
by Subrata Banik (Code Review) 30 Apr '24

30 Apr '24

Attention is currently required from: Andrey Petrov, Karthik Ramasubramanian, Matt DeVillier, Ronak Kanabar, Tim Van Patten. Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/82121?usp=email ) Change subject: drivers/intel/fsp2_0: Release bmp_logo during READY_TO_BOOT stage ...................................................................... Patch Set 2: (1 comment) Patchset: PS2: what if any platform decide to not call into fsp notify phases … [View More]

1 0

[XS] Change in coreboot[main]: soc/intel/xeon_sp: Clean up device enablement configuration
by Felix Singer (Code Review) 30 Apr '24

30 Apr '24

Felix Singer has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/82120?usp=email ) Change subject: soc/intel/xeon_sp: Clean up device enablement configuration ...................................................................... Set Ready For Review -- To view, visit https://review.coreboot.org/c/coreboot/+/82120?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: main … [View More]

1 0

[S] Change in coreboot[main]: soc/intel/cannonlake: Clean up device enablement configuration
by Felix Singer (Code Review) 30 Apr '24

30 Apr '24

Felix Singer has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/82118?usp=email ) Change subject: soc/intel/cannonlake: Clean up device enablement configuration ...................................................................... Set Ready For Review -- To view, visit https://review.coreboot.org/c/coreboot/+/82118?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: … [View More]

1 0

[S] Change in coreboot[main]: block/fast_spi: Use read32p/write32p for SPI RW
by Subrata Banik (Code Review) 30 Apr '24

30 Apr '24

Attention is currently required from: Arthur Heymans, Ashish Kumar Mishra, Patrick Rudolph, Paul Menzel, Saurabh Mishra. Subrata Banik has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/82079?usp=email ) Change subject: block/fast_spi: Use read32p/write32p for SPI RW ...................................................................... Patch Set 6: Code-Review+2 -- To view, visit https://review.coreboot.org/c/coreboot/+/82079?usp=email To unsubscribe, or for … [View More]

1 0

[XS] Change in coreboot[main]: drivers/intel/fsp2_0: Release bmp_logo during READY_TO_BOOT stage
by Karthik Ramasubramanian (Code Review) 30 Apr '24

30 Apr '24

Attention is currently required from: Andrey Petrov, Ronak Kanabar. Hello Andrey Petrov, Ronak Kanabar, I'd like you to reexamine a change. Please visit https://review.coreboot.org/c/coreboot/+/82121?usp=email to look at the new patch set (#2). Change subject: drivers/intel/fsp2_0: Release bmp_logo during READY_TO_BOOT stage ...................................................................... drivers/intel/fsp2_0: Release bmp_logo during READY_TO_BOOT stage bmp_load_logo() loads … [View More]

1 0

[XS] Change in coreboot[main]: soc/amd/mendocino: Allocate the buffer from heap to load logo.bmp
by Karthik Ramasubramanian (Code Review) 30 Apr '24

30 Apr '24

Karthik Ramasubramanian has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/82121?usp=email ) Change subject: soc/amd/mendocino: Allocate the buffer from heap to load logo.bmp ...................................................................... soc/amd/mendocino: Allocate the buffer from heap to load logo.bmp bmp_load_logo() loads the custom logo.bmp file into CBMEM. This cbmem buffer is released after FSP-S init is complete. In certain platforms, the logo file … [View More]is displayed during PCI enumeration. This means the logo buffer is used after it is released. Fix this issue by releasing the logo buffer when the coreboot has finished loading payload. During S3 scenario CBMEM is locked, bmp logo is not loaded and hence the release is a no-op. BUG=b:337144954 TEST=Build Skyrim BIOS Image and boot to OS. Ensure that the chromeOS boot logo is seen without any corruption. Change-Id: Id27cf02de04055075e7c1cb0ae531dee8524f828 Signed-off-by: Karthikeyan Ramasubramanian <kramasub(a)google.com> --- M src/drivers/intel/fsp2_0/notify.c M src/drivers/intel/fsp2_0/silicon_init.c 2 files changed, 5 insertions(+), 4 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/21/82121/1 diff --git a/src/drivers/intel/fsp2_0/notify.c b/src/drivers/intel/fsp2_0/notify.c index 22bbf53..15a1e04 100644 --- a/src/drivers/intel/fsp2_0/notify.c +++ b/src/drivers/intel/fsp2_0/notify.c @@ -2,6 +2,7 @@ #include <arch/null_breakpoint.h> #include <bootstate.h> +#include <bootsplash.h> #include <console/console.h> #include <cpu/x86/mtrr.h> #include <fsp/util.h> @@ -105,8 +106,11 @@ display_mtrrs(); fsp_notify(phase); - if (phase == READY_TO_BOOT) + if (phase == READY_TO_BOOT) { + if (CONFIG(BMP_LOGO)) + bmp_release_logo(); fsp_notify(END_OF_FIRMWARE); + } } BOOT_STATE_INIT_ENTRY(BS_DEV_ENABLE, BS_ON_ENTRY, fsp_notify_dummy, (void *)AFTER_PCI_ENUM); diff --git a/src/drivers/intel/fsp2_0/silicon_init.c b/src/drivers/intel/fsp2_0/silicon_init.c index 52d714d..2287a9e 100644 --- a/src/drivers/intel/fsp2_0/silicon_init.c +++ b/src/drivers/intel/fsp2_0/silicon_init.c @@ -142,9 +142,6 @@ timestamp_add_now(TS_FSP_SILICON_INIT_END); post_code(POSTCODE_FSP_SILICON_EXIT); - if (CONFIG(BMP_LOGO)) - bmp_release_logo(); - fsp_debug_after_silicon_init(status); fsps_return_value_handler(FSP_SILICON_INIT_API, status); -- To view, visit https://review.coreboot.org/c/coreboot/+/82121?usp=email To unsubscribe, or for help writing mail filters, visit https://review.coreboot.org/settings Gerrit-Project: coreboot Gerrit-Branch: main Gerrit-Change-Id: Id27cf02de04055075e7c1cb0ae531dee8524f828 Gerrit-Change-Number: 82121 Gerrit-PatchSet: 1 Gerrit-Owner: Karthik Ramasubramanian <kramasub(a)google.com> Gerrit-MessageType: newchange [View Less]

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
330
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit April 2024