coreboot

coreboot@coreboot.org

6 participants
39686 discussions

[coreboot - Bug #508] (New) Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled
by Yu-Ping Wu 18 Oct '23

18 Oct '23

Issue #508 has been reported by Yu-Ping Wu. ---------------------------------------- Bug #508: Dojo fails to boot from NVMe with CONFIG_RESOURCE_ALLOCATION_TOP_DOWN enabled https://ticket.coreboot.org/issues/508 * Author: Yu-Ping Wu * Status: New * Priority: Normal * Assignee: Nico Huber * Target version: none * Start date: 2023-08-31 * Affected versions: 4.21 ---------------------------------------- Similar to #499, after https://review.coreboot.org/c/coreboot/+/75012, Dojo fails to boot. Disabling CONFIG_RESOURCE_ALLOCATION_TOP_DOWN fixes the problem. However I'm not sure how to fix it from MediaTek's PCIe functions or settings (for example mtk_pcie_domain_read_resources). ---Files-------------------------------- ap-bad.log (32.8 KB) -- 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

2 5

coreboot Leadership Meeting
by mina＠coreboot.org 16 Oct '23

16 Oct '23

Dear coreboot Community, We are pleased to announce the upcoming coreboot leadership meeting scheduled for October 18, 2023[1]. Please add things you wish to see addressed during the meeting to the agenda[2]. # Current Agenda Items * [Martin] OSFC was fantastic. It was great to see everyone who could attend. Hopefully the economy is better next year so we can have more attendees. * [Martin (for Ron)] Our current website looks like an open source project’s website. If we want to convince people to use or work with coreboot, it should look like a company’s website. Ron pointed to [https://go.dev/](https://go.dev/) with their table of “Companies using go” as an example of what he thinks might be better. Listing these companies makes other companies feel like they may be missing out by not using go. * [Martin] coreboot gerrit statistics: [https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC… This is a set of statistics that I’ve been keeping unofficially for a while. I showed it to some people at OSFC, and they suggested sharing it more widely. The data is collected from gerrit with the gerrit_stats perl script in the util/release directory: [https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… Please note - These statistics are terrible for specifics, and can definitely be gamed. Patches vary in quality, and some people choose to spread their patches into a large number, while others choose to do everything in a single patch. Please don’t read too much into anything in these charts. * [Martin] We have a new coreboot store - [https://coreboot.myspreadshop.com](https://coreboot.myspreadshop.com). This is in the US, but we can create a similar store with their European group. Unfortunately, that needs to be set up and configured separately. This is just a typical swag store where you can get the coreboot logo printed on random stuff. Anyone need a coreboot apron? This is being run by Martin, not the coreboot project, so that the project doesn’t have to deal with taxes and such. Any profits made will be donated to coreboot through the SFC. If anyone wants a new design added, let me know. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

coreboot Leadership Meeting
by mina＠coreboot.org 16 Oct '23

16 Oct '23

1 0

coreboot Leadership Meeting
by mina＠coreboot.org 16 Oct '23

16 Oct '23

Dear coreboot Community, We are pleased to announce the upcoming coreboot leadership meeting scheduled for October 18, 2023[1]. Please add things you wish to see addressed during the meeting to the agenda[2]. # Current Agenda Items *[Martin] OSFC was fantastic. It was great to see everyone who could attend. Hopefully the economy is better next year so we can have more attendees. *[Martin (for Ron)] Our current website looks like an open source project’s website. If we want to convince people to use or work with coreboot, it should look like a company’s website. Ron pointed to https://go.dev/ (https://go.dev/) with their table of “Companies using go” as an example of what he thinks might be better. Listing these companies makes other companies feel like they may be missing out by not using go. *[Martin] coreboot gerrit statistics: https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC… (https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC…) This is a set of statistics that I’ve been keeping unofficially for a while. I showed it to some people at OSFC, and they suggested sharing it more widely. The data is collected from gerrit with the gerrit_stats perl script in the util/release directory: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util… (https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util…) Please note - These statistics are terrible for specifics, and can definitely be gamed. Patches vary in quality, and some people choose to spread their patches into a large number, while others choose to do everything in a single patch. Please don’t read too much into anything in these charts. *[Martin] We have a new coreboot store - https://coreboot.myspreadshop.com (https://coreboot.myspreadshop.com). This is in the US, but we can create a similar store with their European group. Unfortunately, that needs to be set up and configured separately. This is just a typical swag store where you can get the coreboot logo printed on random stuff. Anyone need a coreboot apron? This is being run by Martin, not the coreboot project, so that the project doesn’t have to deal with taxes and such. Any profits made will be donated to coreboot through the SFC. If anyone wants a new design added, let me know. [1] https://coreboot.org/calendar.html [2] https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK…

1 0

RTL8111F MAC address not parsed correctly on new ASUS P8H77-M port
by Kevin Keijzer 16 Oct '23

16 Oct '23

Hello, I have been working on a port/variant for the ASUS P8H77-M, which I recently got from a friend. At this point I have almost everything working, with the exception of the onboard Realtek RTL8111F ethernet NIC. Or at least, it does allow for network traffic, but the MAC address is set to 00:00:00:00:00:05. When I boot the vendor BIOS, the actual MAC address is shown when I run `ip link`. I also have a P8Z77-M with coreboot, which has the same NIC and is overall a pretty similar board. On that board I do not have any issues with the MAC address. Maybe I'm wrong, but I suspect the PCI subvendor and subdevice strings to potentially be the cause of this. When I run `hwinfo` with the vendor BIOS on the P8H77-M, the output shows: path = /devices/pci0000:00/0000:00:1c.4/0000:03:00.0 modalias = "pci:v000010ECd00008168sv00001043sd00008505bc02sc00i00" class = 0x20000 vendor = 0x10ec device = 0x8168 subvendor = 0x1043 subdevice = 0x8505 So the subvendor should be 1043 and the subdevice should be 8505. When I do the same when running my WIP coreboot port on the P8H77-M, I get this: pci device: name = 0000:03:00.0 path = /devices/pci0000:00/0000:00:1c.4/0000:03:00.0 modalias = "pci:v000010ECd00008168sv000010ECsd00008168bc02sc00i00" class = 0x20000 vendor = 0x10ec device = 0x8168 subvendor = 0x10ec subdevice = 0x8168 Here the subvendor and the subdevice are equal to the vendor and the device, which I think is wrong and maybe causes this issue. For reference, I also ran `hwinfo` on the P8Z77-M with coreboot: pci device: name = 0000:04:00.0 path = /devices/pci0000:00/0000:00:1c.5/0000:04:00.0 modalias = "pci:v000010ECd00008168sv00001043sd00008505bc02sc00i00" class = 0x20000 vendor = 0x10ec device = 0x8168 subvendor = 0x1043 subdevice = 0x8505 This shows the same subvendor/subdevice as the vendor BIOS on the P8H77-M. (And this board does *not* have the MAC address issue in coreboot.) So I figured that I could set the subsystemid in overridetree.cb to set these values correctly, but no matter what I try, I can't seem to get any other output than 0x10ec:0x8168. First I tried this: device pci 1c.4 on subsystemid 0x1043 0x8505 device pci 00.0 on end end Then this: device pci 1c.4 on device pci 00.0 on subsystemid 0x1043 0x8505 end end And then this: device pci 1c.4 on subsystemid 0x1043 0x8505 device pci 00.0 on subsystemid 0x1043 0x8505 end end But in all cases, `hwinfo` showed 0x10ec:0x8168 and `ip link` gave me 00:00:00:00:00:05. Interestingly, I did see the values I set reflected in the coreboot log: [DEBUG] PCI: 03:00.0 subsystem <- 1043/8505 [DEBUG] PCI: 03:00.0 cmd <- 103 On the other hand, when I looked in the coreboot log of the P8Z77-M, it didn't set it to those values at all: [DEBUG] PCI: 04:00.0 subsystem <- 1043/84ca [DEBUG] PCI: 04:00.0 cmd <- 103 Yet, `hwinfo` still showed 1043:8505 on that board, and the MAC address was correct. So that made me doubt if these values were retrieved from devicetree.cb at all. Anyway, I am kind of at a loss here.. I have two very similar boards with the same NIC. On one of them the MAC address is parsed correctly, and on the other one it is not. The only difference that I can see is the subdevice/subvendor, but I can't get coreboot to set it correctly, even though the vendor BIOS works fine. As for the P8Z77-M board that doesn't have this issue, I can't even find the string "8505" anywhere when I recursively grep through src/mainboard/asus; yet it does seem to use that as the subdevice id somehow. So where are the subvendor/subdevice strings for the NIC retrieved from then? Or could the MAC address issue be caused by something completely different? -- With kind regards, Kevin Keijzer

1 0

coreboot store & contribution spreadsheet
by coreboot org 12 Oct '23

12 Oct '23

I'm at the OSFC right now, and presented a couple of links. I've set up a very preliminary coreboot store: https://coreboot.myspreadshop.com/ This is mostly just a standard store printing the logo on random *stuff*. The nice thing about this particular store is that you can (for a fee) customize locations, sizes, and the such Here's a sheet with some history of commits to coreboot from 4.0 to 4.21: https://docs.google.com/spreadsheets/d/1q_OdePsm1DHUUJxrO1cWce99lOFd9wKiEZC… Martin

1 0

Alderlake-P DDR4 RVP Graphics issue
by mahesh 10 Oct '23

10 Oct '23

Hi folks, Myself Building image for ADL-P DDR4 RVP, by using coreboot 4.21 & Mrchromebox EDK-II as a UEFI payload. By default, RVP don't have a *"libgfxinit" *support *in coreboot *but with the help of Mrchromebox i have integrated the *"libgfxinit" support.* from make menuconfig->> under devices ->> Graphic Initialization -> libgfxinit Vbt ->> extracted Vbt file from the Stock BIOS with the above config, I am able to see the BIOS Menu only on *uart console* However, on External Monitor (HDMI display) appeared with blank screen (No backlight) I inspected the debug log and it says "*HW.GFX.EDID.Sanitize: EDID header pattern mismatch!".* Debug logs: https://pastebin.com/Y8y78Xv1 kindly please advise the solution for this issue.. Thanks in advance..

1 0

New JPEG decoder available for testing
by Patrick Georgi 07 Oct '23

07 Oct '23

Hi everybody, coreboot has a "bootsplash" feature that allows showing an image on the screen relatively early during boot (although rather late in terms of coreboot). It comes with a JPEG decoder that served us for last nearly 20 years, although it is rather limited: It only supports a subset of JPEG's features, so care had to be taken to pre-process the bootsplash image in just the right way for the decoder to accept it. It was also somewhat fragile: util/fuzz-tests/ ships a test harness for our JPEG API, and afl-fuzz++ runs into lots of crashes with that decoder. Enter Wuffs[0]: It's a programming language tailored towards processing "some piece of data" into "another piece of data", with very strict semantics. It comes with a standard library implementing all kinds of things that fit that category from deflate decompression to jpeg. Its compiler emits portable C code, so we don't need to support the language in the coreboot environment at all. https://review.coreboot.org/78271 integrates a pre-release version of Wuffs, replacing our jpeg decoder with the one from there. If you're dealing with bootsplashes, I'd appreciate testing on your image files to see how well it fares. Regards, Patrick PS: Many thanks to Nigel Tao, Wuffs' principal author, who dug through the complications of relicensing the project so it becomes compatible with GPLv2, enabling this integration. [0] https://github.com/google/wuffs

1 0

Re: [NixOS/nixpkgs] Build failure: diffoscobe broken by coreboot-utils 4.21 upgrade (Issue #256896)
by ehaouas 06 Oct '23

06 Oct '23

Hi Ivan, Please send an email to coreboot(a)coreboot.org Thx De : "Ivan Jager" A : "NixOS/nixpkgs" ,"Elyes HAOUAS" ,"Mention" Envoyé: samedi 23 Septembre 2023 15:19 Objet : [NixOS/nixpkgs] Build failure: diffoscobe broken by coreboot-utils 4.21 upgrade (Issue #256896) Steps To Reproduce Steps to reproduce the behavior: build diffoscope Eg: nix-build -A diffoscope Build log https://gist.github.com/aij/ffc8e357eed2c6f4411910972ce0b920 Additional context Broken since #251110 merged per git bisect I looked into this a bit and I'm not sure if it's a diffoscope bug or a coreboot bug. The failing tests generate test files with cbfstool (from coreboot) and the files generated by cbfstool 4.21 are using 4 bytes less space for the "header" (trailer) at the end of the file: $ diffoscope coreboot1.rom.4.20 coreboot1.rom.4.21 --- coreboot1.rom.4.20 +++ coreboot1.rom.4.21 @@ -2039,10 +2039,10 @@ 00007f60: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007f70: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007f80: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007f90: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007fa0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007fb0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00007fc0: ffff ffff ffff ffff ffff ffff ffff ffff ................ -00007fd0: ffff ffff ffff ffff ffff ffff 4f52 4243 ............ORBC -00007fe0: 3131 3132 0000 8000 0000 0000 0000 0040 1112...........@ -00007ff0: 0000 0000 0000 0001 ffff ffff dcff ffff ................ +00007fd0: ffff ffff ffff ffff ffff ffff ffff ffff ................ +00007fe0: 4f52 4243 3131 3132 0000 8000 0000 0000 ORBC1112........ +00007ff0: 0000 0040 0000 0000 0000 0001 e0ff ffff ...@............ As a result, CbfsFile.recognizes does not match. My first thought was to change the matcher @@ -139,7 +138,7 @@ class CbfsFile(File): rel_offset = struct.unpack("<i", f.read(4))[0] if ( rel_offset < 0 - and -rel_offset > CBFS_HEADER_SIZE + and -rel_offset >= CBFS_HEADER_SIZE and -rel_offset < size ): f.seek(rel_offset, io.SEEK_END) but then the rom2 tests still fail... Looking into the relevant change on the coreboot side it looks like the change to the cbfs_header size may have been accidental. (C99 flexible arrays are nice for filename and data but not for fixed size padding...) Anyway, even if this is a coreboot bug, it may still be useful to update diffutils to be able to recognize files produced by coreboot 4.21. Notify maintainers Diffoscope: @dezgeg @danielfullmer @RaitoBezarius coreboot-utils: @felixsinger @yuka Other: @ElyesH @jmbaur @felixsinger @lamby Metadata Please run nix-shell -p nix-info --run "nix-info -m" and paste the result. ivan@tobati:~/nixops/aij/unstable$ nix-shell -p nix-info --run "nix-info -m" - system: `"x86_64-linux"` - host os: `Linux 6.1.50, NixOS, 23.11 (Tapir), 23.11.git.bfb7dfec93f3` - multi-user?: `yes` - sandbox: `yes` - version: `nix-env (Nix) 2.17.0` - channels(root): `"nixos-21.11pre329341.9e70e9f732f"` - nixpkgs: `/etc/nixos/aij/unstable` — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: <NixOS/nixpkgs/issues/256896(a)github.com>

2 1

Re: The GIT server on the downloads page is unreachable suddenly
by Martin Roth 05 Oct '23

05 Oct '23

Hey Gregg, Glad to help. I'm sure there are plenty of others on the mailing list that aren't familiar with uptime.coreboot.org as well. After I sent the email, I did notice that you referenced an old url that is no longer active - http://review.coreboot.org/p/coreboot/. We retired the /p url a couple of years ago, as I recall. Unfortunately I don't remember where it used to point, but I'm suspecting the replacement is this url: https://review.coreboot.org/plugins/gitiles/coreboot You shouldn't see the error you referenced at that url, but you'd get a 404 instead, which is also sub-optimal. Take care. Martin Oct 5, 2023, 10:01 by gregg.drwho8(a)gmail.com: > Hello! > That's what I wanted to know. Good to know of course. Mostly because > early on I needed to redo this laptop, and that meant starting all > over again inside the WSL framework. Sadly the firewall I use cannot > tell the difference between a malicious activity and a planned and > proper one, so it blocked the first, and wanted to do so when I > confirmed for myself that it does work, So all is well. > ----- > Gregg C Levine gregg.drwho8(a)gmail.com > "This signature fought the Time Wars, time and again." > > On Thu, Oct 5, 2023 at 11:33 AM Martin Roth <gaumless(a)tutanota.com> wrote: > >> >> Hi Greg, >> Sorry about any outages that the server has suffered. Obviously, keeping things online is very important to us, but unfortunately, outages do happen for various reasons. >> >> Monitoring of coreboot sites and services is done at https://uptime.coreboot.org - that's where you can check the status of everything. >> You can check the git service here: https://uptime.coreboot.org/service/22 >> >> That said, I don't see any serious outages in the logs for the past few days, so maybe the issue you were seeing was somewhere else on the internet? >> >> Either way, everything seems to be working at this point, so hopefully you aren't seeing any issue. If you still are, it doesn't seem to be a coreboot issue directly. >> >> Take care >> Martin >> >> Oct 4, 2023, 19:16 by gregg.drwho8(a)gmail.com: >> >> > Hello! >> > I just tried to retrieve a fresh set for the coreboot materials from >> > the site and my WSL set complains that git clone >> > https://review.coreboot.org/coreboot.git does not work because the >> > server is itself unreachable. For example when trying to update an old >> > install of the code on the server and I get this response: >> > fatal: unable to access 'http://review.coreboot.org/p/coreboot/': >> > Could not resolve host: review.coreboot.org >> > ----- >> > Gregg C Levine gregg.drwho8(a)gmail.com >> > "This signature fought the Time Wars, time and again." >> > _______________________________________________ > coreboot mailing list -- coreboot(a)coreboot.org > To unsubscribe send an email to coreboot-leave(a)coreboot.org >

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot