coreboot January 2022

coreboot@coreboot.org

25 participants
27 discussions

Denverton-NS refactoring
by Jeff Daly 19 Jan '22

19 Jan '22

A bit of background: I work for Silicom USA and we have several platforms designed around Denverton-NS. Prior to coming to Silicom I was a BIOS architect for Intel, being employed there for 19 years. I was one of the original BIOS engineers for Denverton back when it was first released and ADI Engineering (which became Silicom USA) was a design partner. We still have several customers that use Coreboot on our platforms. When I came on board a year ago I noted that the version we were maintaining was fairly old. Since that time the Intel SoC support has evolved and uses a lot of common code (yay!) but Denverton doesn 't seem to have kept up. Not sure if the maintainers from Intel are still active or not, but I'm sending them an email to see. Over the past few weeks I've brought Denverton support up to date with the Intel SoC common codebase and will be submitting wholesale changes to the tree to do this. Unfortunately, since the code sort of languished for so long, it's not a task that's easily broken up into smaller bits since much of the bits are intertwined across several functional blocks (GPIOs, PMC, ACPI, CPU, etc). While the current in-tree version of Denverton support uses some SOC_INTEL_COMMON_BLOCK_XXXX bits, I've updated the support to use much more and wondering what might be the best way to submit the refactor for easier review. List of supported common bits for Denverton: SOC_INTEL_COMMON_BLOCK SOC_INTEL_COMMON_BLOCK_CPU SOC_INTEL_COMMON_BLOCK_CPU_MPINIT SOC_INTEL_COMMON_BLOCK_SA SOC_INTEL_COMMON_BLOCK_ACPI SOC_INTEL_COMMON_PMC SOC_INTEL_COMMON_BLOKC_PMC_DISCOVERABLE SOC_INTEL_COMMON_BLOCK_ITSS SOC_INTEL_COMMON_BLOCK_TIMER SOC_INTEL_COMMON_BLOCK_P2SB SOC_INTEL_COMMON_BLOCK_GPIO SOC_INTEL_COMMON_BLOCK_ACPI_GPIO SOC_INTEL_COMMON_BLOCK_SPI SOC_INTEL_COMMON_BLOCK_FAST_SPI SOC_INTEL_COMMON_BLOCK_PCR SOC_INTEL_COMMON_BLOCK_LPC SOC_INTEL_COMMON_BLOCK_SMBUS SOC_INTEL_COMMON_BLOCK_TCO SOC_INTEL_COMMON_BLOCK_TCO_ENABLE_THROUGH_SMBUS SOC_INTEL_COMMON_BLOCK_PCIE SOC_INTEL_COMMON_BLOCK_RTC SOC_INTEL_COMMON_BLOCK_SMM SOC_INTEL_COMMON_BLOCK_SMM_IO_TRAP SOC_INTEL_OMMON_BLOCK_POWER_LIMIT

8 18

Intel Atom X5 or X7 support
by josef 15 Jan '22

15 Jan '22

hello,i have been reading your documents for few hours, i know your code can create bios for mainboards, it is great.but i have a question, i like to make a custom board with Intel Atom SOC (eg. Intel Atom x7-Z8700). is your codes support creating BIOS for such SOC's too ? i did see you had some support on one UP board with n3000 series SOC. i have been looking for such a thing for more than a year without any luck. Intel wants millions of dollars that i don't have! among other problems. so, before i dive into your system, i like to know if it is workable.thank you, best regards, Josef.

1 0

[Coreboot] [GSoC 2022] Interested in Contributing
by Ahamed Husni 13 Jan '22

13 Jan '22

Hi all, I am an undergraduate student interested to learn and contribute to Coreboot. I have no prior experience in Coreboot related development. Once I tried to add heap overflow detection support in AddressSanitizer [Patch <https://review.coreboot.org/c/coreboot/+/51787>] as an extension to the GSoC 2020 ASan project. I find the following projects interesting to me. 1. U-Boot EFI Payload integration (New) 2. Port payloads to ARM, AArch64 or RISC-V <https://doc.coreboot.org/contributing/project_ideas.html#port-payloads-to-a…> If I could get the following information regarding the projects, it'll be really helpful. - Prerequisites for each project - Size of the projects (medium:~175 hours, large:~350 hours - from GSoC blog) - Required hardwares I have some experience with C programming. Hardwares with me now: - Intel Galileo Gen 2 - Beaglebone Black with JLink - Raspberry Pi 3B+,3A If there are other projects which might interest me, please let me know. Best Regards, Husni.

1 0

My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.
by Keith Hui 10 Jan '22

10 Jan '22

Previously on the resource allocator discussion, I was about to test Arthur's fix for PARALLEL_MP when all my boards suddenly failed to come up. I still refuse to let this legend die, so I managed to get it going again, and look what it did for me in return. First, I plugged the flash chip with vendor firmware to rule out hardware failure. Came up just fine. Excellent! Swapped in my coreboot chip and tried to flash my copy of coreboot (which is still carrying PARALLEL_MP and the fix. It worked!). flashrom knows it has the 440BX chipset but can't seem to convince itself it will work. See the attached log. I have to calmly tell it "laptop=this is not a laptop" and then it works as usual. I don't remember ever having to do this before. Why? If I have a clue I can code up and submit a patch. Back to how it failed to boot in the first place. The hard disk booting stalled after SeaBIOS. Took me hours but eventually I found a line in my serial log that there has been a DMA timeout. Turning UDMA off in devicetree.cb and flash again made it boot again. So I would have to revert 576315e1 (aka CB:40961), but I'm hesitant because that seemed like the reasonable thing to do and it should have worked. So I'm also unsure why it didn't. Thanks Keith

2 1

"Private" changes on Gerrit are now disabled and removed
by Patrick Georgi 04 Jan '22

04 Jan '22

Hi everybody, it came to my attention that changes marked "private" on Gerrit are hidden in the UI but easily accessible through gitiles and with "git fetch". I don't think it matters for most cases, but since we advertised it as being accessible for the owner and individual reviewers, I didn't want to keep things exposed, especially not after there's an announcement that such access is possible (as through this email). Therefore I: - disabled the "private" CL feature in the Gerrit UI, so you can't mark changes as private - created per-account git bundles[1] of their private CLs. Since I don't want to spam a few hundred users with stuff they might not care about, this is a pull transaction: if you want them, reach out to me. - removed the private commits and references from the coreboot.git repo. You might still see the changes in the UI but that's due to its aggressive caching: The UI actually honors the private flag, so that's not a concern and all other means of accessing commits access the repo and will fail on these now-gone commits. https://review.coreboot.org/c/coreboot/+/59229 also proposes updating the docs to remove mentions of the "private change" feature. As an alternative we could also decide to re-enable the feature but with documentation pointing out that there are ways for motivated unauthenticated users to access these commits, which makes them more of a structuring feature (keep things out of sight until they're ready). In that case I could also reinstate the commits I deleted from the repo. Thoughts? Best regards, Patrick [1] https://git-scm.com/docs/git-bundle

7 11

[coreboot - Bug #335] (New) High prority bug causes bricking when tianocore and flash log console used together
by coreboot＠fe80.eu 04 Jan '22

04 Jan '22

Issue #335 has been reported by xinhua wang. ---------------------------------------- Bug #335: High prority bug causes bricking when tianocore and flash log console used together https://ticket.coreboot.org/issues/335 * Author: xinhua wang * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- With tianocore payload. spi flash console was working here is my log of where it hang BS: BS_DEV_INIT run times (exec / console): 209 / 87 ms FMAP: area SMMSTORE found @ 690000 (262144 bytes) smm store: 4 # blocks with size 0x10000 SMMSTORE: Setting up SMI handler BS: BS_DEV_INIT exit times (exec / console): 0 / 1 ms Finalize devices... PCI: 00:1f.0 final apm_control: Finalizing SMM. ÿ (then all yyyy) any ideas? Thx Maybe block spi flash console from being used when payload is tianocore before its resolved? It causes bricking of system for those who dont have ch341/soic clip/in circuit flashing/bios header to recover easily -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Re: My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.
by Branden Waldner 01 Jan '22

01 Jan '22

Hi > I have to calmly tell it "laptop=this is not a laptop" and then it works as usual. I don't remember > ever having to do this before. Why? If I have a clue I can code up and submit a patch. If I recall correctly both my p2b and p2-99 boards do that while running vendor firmware, though I don't recall ever seeing it while running coreboot (which I just checked to verify it still doesn't show up). > Back to how it failed to boot in the first place. The hard disk booting stalled after SeaBIOS. Took > me hours but eventually I found a line in my serial log that there has been a DMA timeout. > Turning UDMA off in devicetree.cb and flash again made it boot again. So I would have to revert > 576315e1 (aka CB:40961), but I'm hesitant because that seemed like the reasonable thing to do > and it should have worked. So I'm also unsure why it didn't. I've had the occasional issue with my p2-99 in the past, but I've always got it booting again after reseating chips (flash/memory/cpu card). I guess I should be making sure to have the serial link set up more often, I normally only use it when I have a known bad version of coreboot flashed. I actually have the cable connected between the two boards right now, which seems to work decently for testing. Branden

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot January 2022