coreboot March 2022

coreboot@coreboot.org

33 participants
33 discussions

Multi domain PCI resource allocation: How to deal with multiple root busses on one domain
by Arthur Heymans 18 Mar '22

18 Mar '22

Hi I've recently tried to improve the soc/intel/xeon_sp codebase. I want to make it use more native coreboot structures and codeflows instead of parsing the FSP HOB again and again to do things. Ideally the HOB is parsed only once in ramstage, parsed into adequate native coreboot structures (struct device, struct bus, chip_info, ...) and used later on. The lowest hanging fruit in that effort is resource allocation. Currently the coreboot allocator is sort of hijacked by the soc code and done over again. The reason for this is that xeon_sp platforms operate a bit differently than most AMD and Intel Client hardware: there are multiple root busses. This means that there are PCI busses that are in use, but are not downstream from PCI bus 0. In hardware terminology those are the IIO and other type of Stacks. Each Stack has its own range of usable PCI Bus numbers and decoded IO and MEM spaces below and above 4G. I tried to map these hardware concepts to the existing coreboot 'domain' structure. Each domain has resource windows that are used to allocate children devices on, which would be the PCI devices on the stacks. The allocator needs some tweaks to allow for multiple resources of a type (MEM or IO), but nothing major. See https://review.coreboot.org/c/coreboot/+/62353/ and https://review.coreboot.org/c/coreboot/+/62865 (allocator rewrite/improvement based on Nico's excellent unmerged v4.5 work) This seems to work really well and arguably even better than how it is now with more elegant handling of above and below 4G resources. Now my question is the following: On some Stacks there are multiple root busses, but the resources need to be allocated on the same window. My initial idea was to add those root busses as separate struct bus in the domain->link_list. However currently the allocator assumes only one bus on domains (and bridges). In the code you'll see a lot of things like for (child = domain->link_list->children; child; child = child->sibling) .... This is fine if there is only one bus on the domain. Looping over link_list->next, struct bus'ses is certainly an option here, but I was told that having only one bus here was a design decision on the allocator v4 rewrite. I'm not sure how common that assumption is in the tree, so things could be broken in awkward ways. Do you have any suggestions to move forward? Kind regards Arthur Heymans

7 22

New array-bounds warnings with GCC 12
by Paul Menzel 15 Mar '22

15 Mar '22

Dear coreboot folks, *gcc-12* snapshot packages are available in Debian sid/unstable, and build testing coreboot with that shows new array out of bounds warnings. For qemu/i440fx: ``` $ gcc-12 --version gcc-12 (Debian 12-20220313-1) 12.0.1 20220314 (experimental) [master r12-7638-g823b3b79cd2] Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ make V=1 […] x86_64-linux-gnu-gcc-12 -MMD -Isrc -Isrc/include -Isrc/commonlib/include -Isrc/commonlib/bsd/include -Ibuild -I3rdparty/vboot/firmware/include -include src/include/kconfig.h -include src/include/rules.h -include src/commonlib/bsd/include/commonlib/bsd/compiler.h -I3rdparty -D__BUILD_DIR__=\"build\" -Isrc/arch/x86/include -D__ARCH_x86_32__ -pipe -g -nostdinc -std=gnu11 -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough -Wshadow -Wdate-time -Wtype-limits -Wvla -Wdangling-else -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer -fstrict-aliasing -ffunction-sections -fdata-sections -fno-pie -Wno-packed-not-aligned -fconserve-stack -Wnull-dereference -Wreturn-type -Wlogical-op -Wduplicated-cond -Wno-unused-but-set-variable -Werror -Os -Wno-address-of-packed-member -m32 -Wl,-b,elf32-i386 -Wl,-melf_i386 -m32 -fuse-ld=bfd -fno-stack-protector -Wl,--build-id=none -fno-delete-null-pointer-checks -Wlogical-op -march=i686 -mno-mmx -MT build/bootblock/cpu/x86/lapic/lapic.o -D__BOOTBLOCK__ -c -o build/bootblock/cpu/x86/lapic/lapic.o src/cpu/x86/lapic/lapic.c In file included from src/include/cpu/x86/lapic.h:4, from src/cpu/x86/lapic/lapic.c:5: In function 'read32', inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, inlined from 'lapic_read' at src/include/cpu/x86/lapic.h:80:10, inlined from 'lapicid' at src/include/cpu/x86/lapic.h:138:21, inlined from 'enable_lapic' at src/cpu/x86/lapic/lapic.c:41:3: src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 20 | return *((volatile uint32_t *)(addr)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'read32', inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:103:11, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:73:2: src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 20 | return *((volatile uint32_t *)(addr)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'write32', inlined from 'xapic_write' at src/include/cpu/x86/lapic.h:18:2, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:106:3, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:73:2: src/arch/x86/include/arch/mmio.h:40:40: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 40 | *((volatile uint32_t *)(addr)) = value; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ In function 'read32', inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:103:11, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:77:2: src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 20 | return *((volatile uint32_t *)(addr)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'write32', inlined from 'xapic_write' at src/include/cpu/x86/lapic.h:18:2, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:106:3, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:77:2: src/arch/x86/include/arch/mmio.h:40:40: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 40 | *((volatile uint32_t *)(addr)) = value; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ In function 'read32', inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:103:11, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:86:3: src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 20 | return *((volatile uint32_t *)(addr)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'write32', inlined from 'xapic_write' at src/include/cpu/x86/lapic.h:18:2, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:106:3, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:86:3: src/arch/x86/include/arch/mmio.h:40:40: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 40 | *((volatile uint32_t *)(addr)) = value; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ In function 'read32', inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:103:11, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:84:3: src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 20 | return *((volatile uint32_t *)(addr)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'write32', inlined from 'xapic_write' at src/include/cpu/x86/lapic.h:18:2, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:106:3, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:84:3: src/arch/x86/include/arch/mmio.h:40:40: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 40 | *((volatile uint32_t *)(addr)) = value; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ In function 'read32', inlined from 'xapic_read' at src/include/cpu/x86/lapic.h:13:9, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:103:11, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:89:2: src/arch/x86/include/arch/mmio.h:20:16: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 20 | return *((volatile uint32_t *)(addr)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'write32', inlined from 'xapic_write' at src/include/cpu/x86/lapic.h:18:2, inlined from 'lapic_update32' at src/include/cpu/x86/lapic.h:106:3, inlined from 'setup_lapic_interrupts' at src/cpu/x86/lapic/lapic.c:89:2: src/arch/x86/include/arch/mmio.h:40:40: error: array subscript 0 is outside array bounds of 'const volatile void[0]' [-Werror=array-bounds] 40 | *((volatile uint32_t *)(addr)) = value; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ cc1: all warnings being treated as errors ``` I have no idea, if it’s valid or not, but judging from the discussion in the GCC bug report *[11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal* [1], the new behavior is controversial. Could more knowledgeable people please take a look, and give feedback, so in case we consider it a regression for coreboot, we can give feedback to the GCC folks? Kind regards, Paul [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578

3 3

[ANNOUNCE] SeaBIOS 1.16.0
by Kevin O'Connor 15 Mar '22

15 Mar '22

The 1.16.0 version of SeaBIOS has now been released. For more information on the release, please see: https://seabios.org/Releases New in this release: * SMBIOS v3.0 support on QEMU * Several bug fixes and code cleanups. For information on obtaining SeaBIOS, please see: https://seabios.org/Download ===== git shortlog -n rel-1.15.0..rel-1.16.0 ===== Eduardo Habkost (19): biostables: copy_fseg_table() function util.h: Delete unused get_smbios_entry_point() prototype smbios: Rename code specific for SMBIOS 2.1 entry points smbios: Generic smbios_next() function smbios: smbios_get_tables() function smbios: Use smbios_get_tables()/smbios_next() at display_uuid() smbios: smbios_major_version()/smbios_minor_version() helpers tpm: Use smbios_get_tables() csm: Don't check SMBios21Addr before calling copy_smbios_21() smbios: Make SMBios21Addr variable static smbios: Use smbios_next() at smbios_romfile_setup() smbios: Extract SMBIOS table building code to separate function smbios: Make smbios_build_tables() more generic smbios: smbios_21_setup_entry_point() function smbios: Make some smbios_build_tables() arguments optional smbios: Make smbios_build_tables() ready for 64-bit tables smbios: copy_smbios_30() function smbios: Support SMBIOS 3.0 entry point at copy_table() smbios: Support SMBIOS 3.0 entry point at smbios_romfile_setup() Kevin O'Connor (13): vgasrc: Don't use VAR16 in header files to fix gcc warning memmap: Fix gcc out-of-bounds warning readserial: Improve Python3 compatibility scripts: Remove python23compat.py smm: Suppress gcc array-bounds warnings nvme: Rework nvme_io_readwrite() to return -1 on error nvme: Add nvme_bounce_xfer() helper function nvme: Convert nvme_build_prpl() to nvme_prpl_xfer() nvme: Pass prp1 and prp2 directly to nvme_io_xfer() nvme: Build the page list in the existing dma buffer nvme: Only allocate one dma bounce buffer for all nvme drives sercon: Fix missing GET_LOW() to access rx_bytes docs: Note v1.16.0 release Andy Pei (3): virtio-blk: add feature VIRTIO_BLK_F_SIZE_MAX and VIRTIO_BLK_F_SEG_MAX virtio-blk: abstract a function named virtio_blk_op_one_segment to handle r/w request virtio-blk: split large IO according to size_max Igor Mammedov (2): pci: reserve resources for pcie-pci-bridge to fix regressed hotplug on q35 pci: let firmware reserve IO for pcie-pci-bridge Florian Larysch (1): nvme: fix LBA format data structure Gerd Hoffmann (1): svgamodes: add standard 4k modes Jan Beulich via SeaBIOS (1): nvme: avoid use-after-free in nvme_controller_enable()

2 1

something question about coreboot
by Alten_Zheng＠wistron.com 15 Mar '22

15 Mar '22

Hi,I am Alten.A bios enginner. Sorry,I have a question ,what can I to ask about intel platform question or I need to sent the mail. Thank. --------------------------------------------------------------------------------------------------------------------------------------------------------------- This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited. If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately. ---------------------------------------------------------------------------------------------------------------------------------------------------------------

2 1

Re: coreboot has been accepted for GSoC 2022
by Felix Singer 13 Mar '22

13 Mar '22

Hi Ritul, On Sun, 2022-03-13 at 09:03 +0530, ritul guru wrote: > It's been an year I got involved in coreboot up streaming, can I get > more information on kinds of project which I can take part. thanks for your interest! You sent your email only to me. Please make sure that you send the email to the mailing list the next time, so others can also reply :) Please have a look at our announcement [1]. Our project list and our list with many new brainstormed ideas are mentioned there. // Felix [1] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/HLOA…

1 0

Re: Oled switch chipset support
by Ivan Ivanov 13 Mar '22

13 Mar '22

Pls write to whom ported a coreboot to Nintendo Switch, and forward the messages above, to advance. I think a coreboot may be possible at least on t210 newer Switch. I can't find fail0verflow's e-mail. сб, 12 мар. 2022 г. в 20:55, Adolf Hitler <adolfun(a)yahoo.com>: > You seem pretty spot on about the situation, but Im not sure why it wasnt > mentioned or brought up. if i forked somebodys stuff, id tell them incase > they were interested in it > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Friday, March 11, 2022, 10:03 AM, Ivan Ivanov <qmastery16(a)gmail.com> > wrote: > > Well, there's really a coreboot for Nintendo Switch and that's not a > "spam". So, let's discuss the possibility of coreboot for the newer > hardware revisions of Nintendo Switch. At the coreboot repo, I see > "./coreboot/src/soc/nvidia/tegra210" - so there's a coreboot for tegra210 > (don't know its quality though) and I think that coreboot is possible for > "Oled switch" based on t210bo1 chipset (if that's the same as tegra210). > Meanwhile, the possibility of coreboot for tegra214 depends on the > similarity of t210 vs t214 and may be more complicated. Please clarify me > if I'm wrong or you have something to add > > P.S. It a bit puzzles me why the people fork a coreboot behind the scenes > and don't even try to upstream their fork. If I knew there's a coreboot for > switch, I'd have been more likely to buy it (although it's a crappy Nvidia > known for its' hate towards the opensource, so...) > > ср, 9 мар. 2022 г. в 21:19, Adolf Hitler <adolfun(a)yahoo.com>: > > > [image: Inline image] > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Wednesday, March 9, 2022, 1:16 PM, Adolf Hitler <adolfun(a)yahoo.com> > wrote: > > Oled switch chipset: t210bo1 or t214, theres two revisions > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Wednesday, March 9, 2022, 1:09 PM, Adolf Hitler <adolfun(a)yahoo.com> > wrote: > > Absolutely. Im not the person who forked coreboot for nintendo products, > but it is used to boot android and linux for these devices. Heres the > github fork: GitHub - fail0verflow/switch-coreboot: coreboot for the > Switch <https://github.com/fail0verflow/switch-coreboot> > > GitHub - fail0verflow/switch-coreboot: coreboot for the Switch > > coreboot for the Switch. Contribute to fail0verflow/switch-coreboot > development by creating an account on GitHub. > <https://github.com/fail0verflow/switch-coreboot> > > > Mariko chipset: believe its a special tegra x1+ But could ask some more > people and find more info > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Wednesday, March 9, 2022, 5:01 AM, Ivan Ivanov <qmastery16(a)gmail.com> > wrote: > > Wow, I didn't know there's a coreboot for Nintendo! Why you guys > didn't even try to commit this source code to the official coreboot > repository? Please, could you share a link to the "coreboot for > nintendo" forked repository, as well as let us know what chipset this > Mariko is using? This will help us to answer your questions about the > possibility of coreboot on Mariko rev of Nintendo Switch > > чт, 3 мар. 2022 г. в 14:37, Adolf Hitler via coreboot < > coreboot(a)coreboot.org>: > > > > > > So its my understanding that mariko and above boards of nintendo switch > have issues with coreboot but the revisions below do not; are there any > plans to support the new chipset in the oled switches so we can have the > same internal reach as older switches? > > > > Sent from Yahoo Mail for iPhone > > > _______________________________________________ > > coreboot mailing list -- coreboot(a)coreboot.org > > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >

1 0

[GSoC 2022] Interested in Contributing to coreboot.
by Ahamed Husni 12 Mar '22

12 Mar '22

Dear All, I am hoping to apply for the GSoC 2022 program. I am really interested in contributing to the coreboot project as I love to work with low level development. I completed the pre-requisites mentioned in the documentation. I built a 32-bit EFI binary in the gnu-efi environment. I used U-Boot as the payload for coreboot to test this EFI binary. The target is x86_64(QEMU). Serial output: https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3 I sent a patch for review about a year ago related to adding heap-out-of-bound detection support to AddressSanitizer port. If this is not acceptable as my first patch for review, please let me know. I can fix some coding styles or do a simple task given by the community. PATCH: https://review.coreboot.org/c/coreboot/+/51787 I find the "*Add U-BOOT's UEFI payload as a coreboot payload*" project mentioned in the coreboot project collection interesting to me. I have no prior experience with UEFI. As a starting point I learned to build and run an EFI binary with coreboot using the U-Boot payload. Please let me know what I should do next to learn and prepare for this project. Thanks & Best regards, Husni.

2 5

coreboot has been accepted for GSoC 2022
by Felix Singer 12 Mar '22

12 Mar '22

Hello coreboot community, We have great news: coreboot has been accepted for this year's Google Summer of Code! Thanks to everyone who made this possible! You can find our GSoC organization page here [1] (unfortunately, newlines were removed from the description, but that’s not our fault). Looking at the timeline [2], this means the next step is discussing exciting projects. We have about a month for this, from now on until April 3rd, and then the application phase starts. It’s not too late to become a mentor! If you are interested, please have a look at the mail [3] I have sent earlier. You also can help with code reviews or working out a project (writing description, defining project scope and tasks, ...). Every bit of help counts. For people interested in being GSoC candidates, we set up a page [4] for all kinds of information and documentation. Please have a look at this, it’s really worth reading it :) We prepared a list of projects [5] and we also started brainstorming more project ideas [6]. No matter whether you want to participate as a GSoC contributor or mentor, if you are interested in any of these, then please let us know. Also, in case you have your own project idea, feel free to reach out. We are excited to have great discussions with you! Your Org Admins, Felix, Martin, David [1] https://summerofcode.withgoogle.com/programs/2022/organizations/coreboot [2] https://developers.google.com/open-source/gsoc/timeline#march_7_-_april_3 [3] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/PGK… [4] https://doc.coreboot.org/contributing/gsoc.html [5] https://doc.coreboot.org/contributing/project_ideas.html [6] https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfc…

2 1

Re: Oled switch chipset support
by Ivan Ivanov 11 Mar '22

11 Mar '22

Well, there's really a coreboot for Nintendo Switch and that's not a "spam". So, let's discuss the possibility of coreboot for the newer hardware revisions of Nintendo Switch. At the coreboot repo, I see "./coreboot/src/soc/nvidia/tegra210" - so there's a coreboot for tegra210 (don't know its quality though) and I think that coreboot is possible for "Oled switch" based on t210bo1 chipset (if that's the same as tegra210). Meanwhile, the possibility of coreboot for tegra214 depends on the similarity of t210 vs t214 and may be more complicated. Please clarify me if I'm wrong or you have something to add P.S. It a bit puzzles me why the people fork a coreboot behind the scenes and don't even try to upstream their fork. If I knew there's a coreboot for switch, I'd have been more likely to buy it (although it's a crappy Nvidia known for its' hate towards the opensource, so...) ср, 9 мар. 2022 г. в 21:19, Adolf Hitler <adolfun(a)yahoo.com>: > > [image: Inline image] > > > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Wednesday, March 9, 2022, 1:16 PM, Adolf Hitler <adolfun(a)yahoo.com> > wrote: > > Oled switch chipset: t210bo1 or t214, theres two revisions > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Wednesday, March 9, 2022, 1:09 PM, Adolf Hitler <adolfun(a)yahoo.com> > wrote: > > Absolutely. Im not the person who forked coreboot for nintendo products, > but it is used to boot android and linux for these devices. Heres the > github fork: GitHub - fail0verflow/switch-coreboot: coreboot for the > Switch <https://github.com/fail0verflow/switch-coreboot> > > GitHub - fail0verflow/switch-coreboot: coreboot for the Switch > > coreboot for the Switch. Contribute to fail0verflow/switch-coreboot > development by creating an account on GitHub. > <https://github.com/fail0verflow/switch-coreboot> > > > Mariko chipset: believe its a special tegra x1+ But could ask some more > people and find more info > > > Sent from Yahoo Mail for iPhone > <https://overview.mail.yahoo.com/?.src=iOS> > > On Wednesday, March 9, 2022, 5:01 AM, Ivan Ivanov <qmastery16(a)gmail.com> > wrote: > > Wow, I didn't know there's a coreboot for Nintendo! Why you guys > didn't even try to commit this source code to the official coreboot > repository? Please, could you share a link to the "coreboot for > nintendo" forked repository, as well as let us know what chipset this > Mariko is using? This will help us to answer your questions about the > possibility of coreboot on Mariko rev of Nintendo Switch > > чт, 3 мар. 2022 г. в 14:37, Adolf Hitler via coreboot < > coreboot(a)coreboot.org>: > > > > > > So its my understanding that mariko and above boards of nintendo switch > have issues with coreboot but the revisions below do not; are there any > plans to support the new chipset in the oled switches so we can have the > same internal reach as older switches? > > > > Sent from Yahoo Mail for iPhone > > > _______________________________________________ > > coreboot mailing list -- coreboot(a)coreboot.org > > To unsubscribe send an email to coreboot-leave(a)coreboot.org > >

1 0

Memory Init failures
by Rao G 11 Mar '22

11 Mar '22

Hi All, On elkhartlake_crb https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/elkhar… ehlcrb_spd_info.read_type = READ_SPD_CBFS; ehlcrb_spd_info.spd_spec.spd_index = 0x00; *Can this setting be changed to READ_SMBUS?* Seeing Memory Init failures in FSP MRC task Early ReadMPR Timing Centering 2D -- FAILED, Status = 6h. Stack Depth: 55724 <MrcTimer Task="Early ReadMPR Timing Centering 2D" msec="766"/> MRC timer: Total time for SAGV Low point = 11955 msec. MRC task -- debug print: 0 MRC timer: Total time to execute tasks = 11955 msec. Memory initialization has failed It would be great if someone can let me know the settings Thanks Ranga

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot March 2022