March 2020 - coreboot - mail.coreboot.org

DRI_PRIME on G505s with enabled dGPU?
by Matt B March 11, 2020

March 11, 2020

Hi, Quick question before I go out and buy a different motherboard for my G505s: To those who have a dual-GPU G505s and have enabled the recent support for the dGPU, does DRI_PRIME GPU offloading work? Thanks, -Matt PS. Could here be an option created to enable/disable the dGPU at boot time without recompiling?

2 1

libgfxinit quick starter guide
by Michal Zygowski March 11, 2020

March 11, 2020

Hi coreboot folks, For some time I have been interested in libgfxinit and I wondered how it works (like in developer details). Particularly I would like to implement Braswell support for native graphics init with libgfxinit. I see the programming manuals from Intel are in place: https://01.org/linuxgraphics/documentation/hardware-specification-prms What do I need to implement a new microarchitecture in libgfxinit? Where to start and what should I focus on? tl;dr; Haven't written anything in SPARK/Ada yet. It will be a new adventure for me. Regards, -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

1 0

Error for missing tools
by Alif Ilhan March 11, 2020

March 11, 2020

I am facing errors while installing superiotool, inteltool, ectool etc. It tells me to install pciutils-devel and zlib-devel packages. But I already have them installed. So how to fix it?

2 1

Porting to a new netbook
by Alif Ilhan March 11, 2020

March 11, 2020

I have found that my EC chip is supported (ITE IT8518E). My netbook is hp mini 110-4100. How do I port coreboot for this netbook?

2 1

Initial mainboard commit - minimal requirements and completion criteria
by Michal Zygowski March 10, 2020

March 10, 2020

Dear coreboot community, I have been trying to merge few mainboard for some time, however I find it difficult to get reviews (and lead it towards merging), despite fulfilling all requests like Documentation entry. Example: https://review.coreboot.org/c/coreboot/+/30360/13#message-7720bf7ed3f447a87… I have rebased it, added Documentation entry, however nobody touched it since I lastly updated it in November. Following the same convention I have updated a Protectli FW6 Kaby Lake board patch today: https://review.coreboot.org/c/coreboot/+/33839/ Probably this week I will also update another mainboard patch with documentation: https://review.coreboot.org/c/coreboot/+/32076 Are there any exit criteria which initial mainboard commit should fulfil to be considered good quality and complete? I have also added changes to MAINTAINERS file (for the FW6) to indicate that these patches will not become a piece of unused and unmaintained code. The first two patches are solid and all issues documented. All of them will receive an entry in MAINTAINERS file. I would very appreciate a little bit of your attention on them and possibly reviews. I especially need the Kaby Lake board, because 3mdeb will soon begin upstreaming changes to support Boot Guard and Protectli FW6 is our reference platform. I don't want the mainboard patches to be a burden or blocking any related efforts. So I kindly ask for a tiny bit of your time to have a look at these patches. Let's improve coreboot together and make it a competitive (and even better) replacement of proprietary BIOS solutions. With kind regards, -- Michał Żygowski Firmware Engineer https://3mdeb.com | @3mdeb_com

3 5

Seeking mentors for Google Summer of Code 2020
by Patrick Georgi March 9, 2020

March 9, 2020

Hi everybody, since we're invited to participate in this year's GSoC and since students can send their project proposals starting next week, I guess now is the time to register potential mentors with the system, so we can triage and assign proposals efficiently. If helping a student get up to speed with coreboot development and open source development in general sounds like a great way to spend your time to you, please consider mentoring! Note to potential student participants: There's a conflict of interest in being both a student and a mentor and so GSoC doesn't allow that. If you consider joining GSoC as a student (for any participating open source project) this year, don't ask to become a mentor. Our expectations of a mentor are: - Being around for most of mid of March (when the applications rush in) to mid of August (when everything wraps up) - Work with the student to build a realistic project plan - Being the point of contact for a specific student working on a specific project from mid of May to mid of August - Following up on their student's progress and helping them along. This usually means: - One or more sync meetings with the student every week (schedule is up to you and your student to sort out) - Being available for helping them when they get stuck - Encourage them to participate in the community. Students with no prior OSS experience are often a bit shy, and a big part of GSoC is to help them get into it. This depends on the student, but can involve being their wingman on IRC, encouraging them to push code for review early and go through the feedback they get together (it often looks scary for new-comers) - 3 evaluations of the student's progress (in mid-June, -July, -August) If that time frame covers a week or two of down time (vacation etc), we can likely handle that (but it helps to know about scheduled off-time in advance!) If it's more, maybe there should be more than one mentor to your student. If you're dropping out due to some unforeseen event, that's on David Hendricks and I (in our function as org admins) to sort out, finding a replacement or jumping in ourselves. If you're interested, feel free to send me a private email and we'll take it from there. Regards, Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

1 0

Re: What does mirror_payload() do and do we still need it?
by Julius Werner March 9, 2020

March 9, 2020

[resend with right account] On Fri, Mar 6, 2020 at 5:50 PM Julius Werner <jwerner(a)google.com> wrote: > > Hi, > > I'm trying to refactor some CBFS code (which necessarily leaks into > the prog_loaders) and > mirror_payload()/CONFIG_MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING is a bit > of a complication. I'm trying to understand if this option is actually > used by anyone. It seems to be "default n" in Kconfig and I don't see > any mainboard/SoC select it specifically. It is not user-visible in > menuconfig and the Chrome OS specific defconfig files don't select it > either. In the original patch > (https://review.coreboot.org/c/coreboot/+/5305) there seems to have > been some discussion about which boards can even benefit from this, > and I don't see any indication that it was ever really enabled > anywhere. > > So is this actually used anywhere, by anyone? Can I just rip it out? > > Thanks, > Julius

2 1

x11ssm-f usb3.0 boot issues
by Valentin March 9, 2020

March 9, 2020

Hello, I've built coreboot with seabios for the Supermicro X11SSM-F motherboard and i'd like to use the internal usb3.0 port with a usb stick as a boot device. If power on the board and do a cold boot the usb works just fine, but if i reboot the system or use the reset button the usb is not recognized in seabios. If i use a usb2 port instead there are no issues at all. I can't figure out the reason for this... has anyone an idea on how to fix this issue or experienced this before? i attached the complete console debug output from a cold and warm boot as well as the config file, any help is appreciated. Thanks, Valentin

2 1

About autoport in coreboot source tree
by Alif Ilhan March 7, 2020

March 7, 2020

Can I use autoport function to port coreboot to any unsupported netbook? Please let me know

2 1

CSME vulnerability
by Jason Lenz March 5, 2020

March 5, 2020

Interesting article today from Positive Technologies. https://www.ptsecurity.com/ww-en/about/news/unfixable-vulnerability-in-inte… I can't tell if this creates an opportunity for users to fully control ME on affected computers (via coreboot/me_cleaner), or if this is a nail in the coffin. In particular the following statement was interesting: "In ROM, this vulnerability also allows for arbitrary code execution at the zero level of privilege of Intel CSME. No firmware updates can fix the vulnerability."

1 0