[coreboot] Re: Enforcing coreboot as lowercase
Hey Arthur, I don't know that enforcing lowercase coreboot in the codebase really has anything to do with the trademark. It was decided a long time ago, before I joined the project, that coreboot was going to be lowercase all the time. We can of course change this decision if desired, but if we're sticking with that decision, it makes sense to try to enforce it in the places that matter most, the codebase, commit messages, and documentation. If it's really such a burden to spell it in lowercase in commit messages that we need to get rid of the check, then let's just change the decision about always using lowercase spelling. Martin Jul 4, 2024 at 09:47 by art...@aheymans.xyz: > Hi > > The coreboot trademark is registered as lowercase. > We enforce this in for instance commits, even when normal grammar would > dictate uppercase at the start of a sentence. > > This makes sense for very well known brands, companies and products like > "eBay", "iPhone", "AMD". They are all very well known trademarks and they > have some uppercase letter in them in atypical places. For these words > grammar exceptions seems reasonable. > > Coreboot is a reasonably well known as a project, but little people know > about the specificity of the trademark. This often causes confusion on people > either reading "coreboot" at the start of a sense, where it looks > grammatically wrong, making it even look unprofessional in the eyes of some. > This is because there is no other uppercase letter inside coreboot that would > make it a typical exception to regular grammar rules. > > People getting into the project making the mistake at the start of a > sentence, might get the wrong impression of too many idiosyncrasies. On top > of that it takes a non zero amount of effort on people in the project to > educate others on this trademark thing. > > Also trademark are typically a bit more broad than exactly how they are > registered. I cannot start a company called iNTel or aMD that makes chips. I > cannot put a product on the market called "IPHoNE". I think the same applies > to "coreboot". > > So my question is: can we relax the trademark in lowercase enforcement? I > would suggest to simply allow both ways. > > Arthur Heymans > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2024-06-26 - coreboot Leadership Meeting Minutes
Jun 27, 2024 at 10:14 by th3fan...@gmail.com: > Hi list, > > On Thu, Jun 27, 2024 at 2:00 PM mina--- via coreboot > wrote: > >> >> # 2024-06-26 - coreboot Leadership Meeting >> > > *snip* > >> ### [Martin] Merge SLOs >> * Can we define objectives for timeframes to get patches merged to >> different areas in the codebase? >> An individual mainboard that doesn’t affect the rest of the codebase doesn’t >> need as much scrutiny >> as core code that affects every platform. >> >> * Mainboard: 1 week? >> ... >> * Add a month SLO for drivers & SIOs initially. >> > > Would it make more sense to aim for timely replies, i.e. avoid patches > sitting unreviewed for an indefinite amount of time? > Sure, that'd be amazing. Do you have a proposal about how to make that happen? The SLOs are to help us see when things are sitting for too long, not to push things in that aren't ready to be merged. Right now we don't really have any sort of method to sort patches and keep things following well. This is simply an attempt to help with that and identify patches to pick up for review in the bi-weekly meetings that are going to be organized. If it doesn't work, we'll soon discover that. > > ... > About helping newcomers, I think what would help the most is to > streamline the review process. For example, be less nitpicky about > style. > That's part of what's being proposed, particularly for areas such as mainboards. > ... > > In addition, having an up-to-date mainboard porting guide (tutorial, > part 4) that helps guide people through the process would be > fantastic, as there have been a few times where pointing others to > such a guide would've been very useful. > > Absolutely! Can you help write that? Can we get volunteers? > ... > > Clarification regarding RVPs: the code for newer RVPs is quite > convoluted for a beginner because variants, ChromeOS support and EC > firmware SKU selection; older RVPs (CML and earlier) are mostly > untested and unmaintained these days, so they're not great to use as a > reference. > Again, I agree, I'm just not sure what to do about it. The reference boards are done for the Si vendors' testing, not as reference for coreboot developers. Any thoughts on how to solve this? > ... > > Because of this, the porting process differs from that used > for the RVPs, where board documentation is available, there's at least > one (if not more) UARTs to get coreboot logs out of, and one may even > have access to blobs' source code. > Again, I agree. What do we do about this? The boards that are being ported are what they are. Can you (or anyone) help document ways to work around these issues? If you have any solutions to these problems, or can figure out how to get the things done that need to to be done, I'd love to hear them. I want to avoid burning out the people we have on the project already. Any concrete ideas along with ways to get them done are welcome. Let's just try to avoid making suggestions that expect someone else to do them. It's easy to say "someone should", but finding that someone is the hard part. Apologies if my tone is hard. Today's a crap day.Martin >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > > Best regards, > Angel > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2024-05-29 - coreboot Leadership Meeting Canceled
Hey Julius, we intended to delete it and got rid of the entry on the coreboot calendar, but forgot that the invite is from my osff calendar. I realized just when the meeting started which is why I joined and let you know. Martin May 29, 2024, 10:09 by jwer...@chromium.org: > Hi Mina, > > The next time this happens, could you please also delete the Google > Calendar event for the meeting? That should be a bit more visible for > those who don't check this list every day. (If Martin owns the event, > I believe he should be able to grant you permission to modify it.) > > Thanks! > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #536] (In Progress) Cannot build coreboot-sdk
Issue #536 has been updated by Martin Roth. Status changed from New to In Progress Pushed https://review.coreboot.org/c/coreboot/+/82411 to switch from debian sid to debian stable. If/After that's merged, we can close this issue. Bug #536: Cannot build coreboot-sdk https://ticket.coreboot.org/issues/536#change-1832 * Author: Michał Żygowski * Status: In Progress * Priority: Normal * Assignee: Martin Roth * Target version: none * Start date: 2024-04-24 I have just tried building coreboot-sdk from scratch and could not get past the step of installing the required packages. Found out that diffutils dependency on libcurl4t64 break libcurl4 (change apt-get to apt to see verbose information message like below): ``` shell > [coreboot-sdk 2/4] RUN useradd -p locked -m coreboot &&apt-get > -qq update && apt -qqy install --no-install-recommends > bash-completion bc bison > bsdextrautils bzip2 ca-certificates > ccache cmake cscope curl > device-tree-compilerdh-autoreconf diffutils >exuberant-ctags flex g++ gawk > gcc git gnat-13 golang > graphicsmagick-imagemagick-compat graphvizlcov >lesslibcapture-tiny-perllibcrypto++-dev > libcurl4libcurl4-openssl-dev > libdatetime-perllibelf-dev libfreetype-dev >libftdi1-devlibglib2.0-dev libgmp-dev > libgpiod-dev libjaylink-dev liblzma-dev > libnss3-dev libncurses-dev libpci-dev > libreadline-dev libssl-dev libtimedate-perl >libusb-1.0-0-devlibxml2-dev > libyaml-dev m4 makemeson > msitoolsneovim ninja-build > openssh-client openssl parted patch > pbzip2 pkg-config python3 > python-is-python3 qemu-system-arm > qemu-system-miscqemu-system-ppc > qemu-system-x86 rsync sharutils > shellcheck unifont unzip uuid-dev >vim-common wgetxz-utils > zlib1g-dev && apt-get clean: 2.106 2.106 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. 2.106 2.841 diffutils is already the newest version (1:3.10-1). 2.841 diffutils set to manually installed. 2.841 Some packages could not be installed. This may mean that you have 2.841 requested an impossible situation or if you are using the unstable 2.841 distribution that some required packages have not yet been created 2.841 or been moved out of Incoming. 2.841 The following information may help to resolve the situation: 2.841 2.841 Unsatisfied dependencies: 3.001 libcurl4t64 : Breaks: libcurl4 (< 8.7.1-3) 3.004 Error: Unable to correct problems, you have held broken packages. ``` Changing libcurl4 to libcurl4t64 allows the docker to continue the build process of coreboot-sdk. But is this the right thing to do? -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #536] Cannot build coreboot-sdk
Issue #536 has been updated by Martin Roth. I just tested this, and was able to reproduce your result with the current dockerfile. I then broke the dockerfile into 4 steps to test a bit. step 1. install everything through libcrypto++-dev step 2. install libcurl4 step 3. install libcurl4-openssl-dev step 4. install everything else. And... of course that worked just fine. Obviously we don't want to actually do that, but it seems to show that it's some weirdness with the install process on debian sid. Honestly, I'm tired of dealing with sid, so I think we're going to look at the possibility of switching to stable, as that's probably a better representation of what people might be using on their own systems. Bug #536: Cannot build coreboot-sdk https://ticket.coreboot.org/issues/536#change-1831 * Author: Michał Żygowski * Status: New * Priority: Normal * Assignee: Martin Roth * Target version: none * Start date: 2024-04-24 I have just tried building coreboot-sdk from scratch and could not get past the step of installing the required packages. Found out that diffutils dependency on libcurl4t64 break libcurl4 (change apt-get to apt to see verbose information message like below): ``` shell > [coreboot-sdk 2/4] RUN useradd -p locked -m coreboot &&apt-get > -qq update && apt -qqy install --no-install-recommends > bash-completion bc bison > bsdextrautils bzip2 ca-certificates > ccache cmake cscope curl > device-tree-compilerdh-autoreconf diffutils >exuberant-ctags flex g++ gawk > gcc git gnat-13 golang > graphicsmagick-imagemagick-compat graphvizlcov >lesslibcapture-tiny-perllibcrypto++-dev > libcurl4libcurl4-openssl-dev > libdatetime-perllibelf-dev libfreetype-dev >libftdi1-devlibglib2.0-dev libgmp-dev > libgpiod-dev libjaylink-dev liblzma-dev > libnss3-dev libncurses-dev libpci-dev > libreadline-dev libssl-dev libtimedate-perl >libusb-1.0-0-devlibxml2-dev > libyaml-dev m4 makemeson > msitoolsneovim ninja-build > openssh-client openssl parted patch > pbzip2 pkg-config python3 > python-is-python3 qemu-system-arm > qemu-system-miscqemu-system-ppc > qemu-system-x86 rsync sharutils > shellcheck unifont unzip uuid-dev >vim-common wgetxz-utils > zlib1g-dev && apt-get clean: 2.106 2.106 WARNING: apt does not have a stable CLI interface. Use with caution in scripts. 2.106 2.841 diffutils is already the newest version (1:3.10-1). 2.841 diffutils set to manually installed. 2.841 Some packages could not be installed. This may mean that you have 2.841 requested an impossible situation or if you are using the unstable 2.841 distribution that some required packages have not yet been created 2.841 or been moved out of Incoming. 2.841 The following information may help to resolve the situation: 2.841 2.841 Unsatisfied dependencies: 3.001 libcurl4t64 : Breaks: libcurl4 (< 8.7.1-3) 3.004 Error: Unable to correct problems, you have held broken packages. ``` Changing libcurl4 to libcurl4t64 allows the docker to continue the build process of coreboot-sdk. But is this the right thing to do? -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Code of conduct: Punishment and revoking privileges (was: coreboot Meetings Announcement And Agenda Call, 21.02.24)
Hi Paul, My responses are inline. Feb 19, 2024, 15:26 by pmen...@molgen.mpg.de: > Dear coreboot folks, > > > Am 19.02.24 um 22:24 schrieb mina--- via coreboot: > > […] > >> ### [Nico] Revoking Gerrit privileges as punishment. >> I would like to discuss two matters about this. Not sure about the order. >> ... >> > In my opinion, some things are missing. > > 1. First, before “punishing” someone the person needs to be informed and > also have the chance to be heard. > The "Punished" person can always email the coreboot leadership or the arbitration team, as mentioned in the code of conduct document in the section marked "Addressing Grievances" Note that there has typically been a significant amount of discussion before any actions are taken, and I don't believe that this case was an exception to that. > 2. If the person wants to discuss this publicly, that should be allowed. > While we can't stop someone from making it public, I think this is a bad plan and cannot do anything good for the community. > 3. The length of the “punishment” must be limited. > When someone has been warned numerous times but simply can't stop themselves from violating the code of conduce, the consequences may be permanent. So far there's only been one permanent ban that I know of, but it was justified in my opinion. > I would keep the status quo. It’s my impression, that until know, these means > were enough. > As I said in the minutes, the status quo is: ``` If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event). ``` What's being added is supposed to be a clarification on that, not an expansion. Note that the current code of conduct does say "without warning". https://doc.coreboot.org/community/code_of_conduct.html > Kind regards, > > Paul > Take care. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: commit 0eab62b makes menuconfig more strict regarding the old configs
Hey Mike, I think you should be able to just append change the kconfig values when you run make to override the current settings. something like `make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0` if we update where they're set in the makefile from := to ?=, you could even just have them set as environment variables so they don't need to be on the command line. I wouldn't suggest that most people do that, but what you're trying to do is a special case. Martin Nov 28, 2023, 11:05 by mikeb...@gmail.com: > In my case, a csb_patcher.sh script [1] - among other things - > delivers the example config files for the opensource AGESA boards. > Although these configs haven't been updated for a while (i.e. a last > update of AMD Lenovo G505S config [2] is 1 year ago), I got away with > this: they are still working, just get refreshed when a user does > "menuconfig" & "make" and result in a working coreboot build. However, > with a commit 0eab62b [3] they are rejected [see 4]. > > Of course I'm going to manually "refresh" the configs to temporarily > fix this problem, but I see this could increase the maintenance burden > and reduce the usefulness of coreboot config files shared online... > Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that > outweigh these potential issues? > > [1] https://review.coreboot.org/c/coreboot/+/64873 > [2] https://review.coreboot.org/c/coreboot/+/64829 > [3] https://review.coreboot.org/c/coreboot/+/79259 > [4] > > ./coreboot/$ make menuconfig > src/soc/intel/meteorlake/Kconfig:457:warning: config symbol defined without > type > ./coreboot/.config:26:warning: unknown symbol: COMPRESS_RAMSTAGE > ./coreboot/.config:230:warning: unknown symbol: ARCH_ALL_STAGES_X86 > ./coreboot/.config:249:warning: unknown symbol: VBT_DATA_SIZE_KB > ./coreboot/.config:256:warning: unknown symbol: UART_PCI_ADDR > ./coreboot/.config:264:warning: unknown symbol: S3_DATA_POS > ./coreboot/.config:265:warning: unknown symbol: S3_DATA_SIZE > ./coreboot/.config:274:warning: unknown symbol: LOGICAL_CPUS > ./coreboot/.config:459:warning: unknown symbol: INTEL_GMA_OPREGION_2_0 > ./coreboot/.config:572:warning: unknown symbol: PAYLOAD_YABITS > ./coreboot/.config:574:warning: unknown symbol: PAYLOAD_TIANOCORE > > ERROR: 10 warnings encountered, and warnings are errors. > > make: *** [build/util/kconfig/Makefile.real:47: menuconfig] Error 1 > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: RFC: Post-build control of serial console
Hey Simon, I think this is a good summary of the current situation, though the table doesn't come through in the text version of the email at all. Maybe upload an RFC to the documentation directory so it can be commented on in gerrit? As I mentioned in the leadership meeting, I have concerns about a solution that relies solely on embedding this in bootblock. Some of these issues are specific to AMD, but if we're doing this, it should be a solution that we can use across different platforms and architectures. Issues I see with embedding it the option mechanism in bootblock:1) Bootblock can be signed for verification by cbfs. Modifying the bootblock will cause the CBFS verification to fail. 2) The AMD bootblock is part of the overall AMDFW binary, and not at the top of the ROM as it used to be. This makes locating it and modifying it more difficult - it's not a separate CBFS area as you specified. 3) For AMD, the bootblock can be compressed, which makes it difficult (or impossible) to update this table.4) AMD has 3 copies of the bootblock. Which one gets updated? If all need to be updated, that's very inconvenient and creates issues keeping them in sync. 5) Assuming that you want this to be available to the 1st stage that's run, on AMD, that doesn't have to be bootblock, that can be PSP_verstage instead. 6) What happens when there's only one bootblock and it's in RO, so the options can't be updated? Maybe that's not an issue for ChromeOS because the table would only be used for debug, but if we're adding something new, let's design it so that it's useful for everyone. I think it would be better to have a single table at a known fixed location in the firmware boot media so that it can be accessed before CBFS is enabled. This can be a separate partition in FMAP and parsed out by Make at build-time, or set as a Kconfig option and put anywhere in flash that is convenient to the architecture or platform (while still being writable). As Arthur said, it's inconvenient when the firmware boot media isn't memory mapped, so we probably need to design this with both options in mind. I'm fine with an option that lets us choose between embedding something in the bootblock and placing the table somewhere else, so long as we use the same format in either place and only have a single copy in any given coreboot.rom image. Also, I'd really like to see this use an existing configuration mechanism instead of adding yet another configuration API. Here are 3 options I see: CMOS_BUT_IN_FLASHOne option is to use the same interface inside coreboot that we currently use for CMOS. We should be able to just read the options from the boot media (or memory after copying it from flash) instead of CMOS, but use the rest of the parsing mechanisms as they already exist. CCB would just be added as another OPTION_BACKEND in Kconfig. I do like the way we have a method of adding default values for CMOS, so I'd prefer to see the exact same mechanism that we use in CMOS, but stored in flash instead. This would work well as an option for either putting into the bootblock or somewhere else in flash. SMMSTORE_VIA_ANOTHER_MECHANISMIf that's not practical, we could use the same partition and format used by SMMstore, and create non-SMM routines to be cross-platform and allow it to be used earlier. It looks like SMMstore can already be used as another OPTION_BACKEND. I haven't looked into SMMstore, so I don't know if this is practical, but this still seems better than creating something completely new. Obviously, this doesn't work well to embed into the bootblock. CBI_IN_FLASHEven extending CBI to read data from the firmware boot media instead of (or in addition to) the EC would be better than creating an entirely new interface. There's a CBI interface to read the bits directly, but CBI also hooks into devicetree allowing devices to be enabled or disabled at runtime. CBI is currently limited to 64 bits, but that could be extended. This also works well for either embedding into bootblock or placing somewhere else in flash. Martin Sep 22, 2023, 13:58 by s...@chromium.org: > Hi, > > Here is an updated version 2 of the RFC > > RFCv2: Post-build control of serial console > > > It is annoying to have to create and maintain two completely different builds > of coreboot just to enable or disable the console. It would be much more > convenient to have a 'silent' flag in the image, which can be updated as > needed, without needing to rebuild > > > coreboot. For example, if something goes wrong and coreboot hangs, it would > be nice to be able to enable serial on the same image, then boot it again to > see how far it gets. > > > > I propose a 'Coreboot Control Block' (CCB) which can hold a small number of > such settings. > > > > It is designed to be available very early in bootblock, before CBFS is ready. > It is a
[coreboot] Re: Patches moved to main branch lost review scores
I'll work on running things through jenkins again, but it's going to take a while to get all of the patches done. If anyone has a specific patch they need to get verified, rebasing it on top of the main branch is a good way to get jenkins to pick it up again. *Please* do not rebase huge patch trains - this ties up the builders for long periods of time and prevents other people from getting their patches checked. 5 or 10 at a time should be okay, but beyond 10 patches, rebase the train in stages so that other people can use the builders as well. This isn't just now - this is a general rule mentioned in the gerrit guidelines document. Martin Sep 12, 2023, 09:44 by felixsin...@posteo.net: > Hi Jeremy, > > Jenkins builds can be just triggered by editing the commit message > without doing any changes to it. Just save it, which updates the commit > date. That is enough to trigger Jenkins. > > For instance, run `git commit --amend`, don't do any changes, just save > it and repush as usual (though with HEAD:refs/for/main now). > > > Felix > > > On Mon, 2023-09-11 at 14:37 -0700, Compostella, Jeremy wrote: > >> Hi, >> >> Most of my gerrit patches moved to the main branch over the >> week-end. But they lost reviews score such +2 or V+1. Typically, >> <https://review.coreboot.org/c/coreboot/+/77615>. If V+1 is mandatory >> how do I trigger the Jenkins gerrit build ? >> >> Regards, >> > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Jenkins V-1 failure due to internal error
Hey Jeremy, I retriggered the build. I thought that at one point we had it set up so that anyone could retrigger the builds, but that doesn't seem to be the case anymore. Let me see if I can fix that. Martin Sep 6, 2023, 16:38 by jeremy.composte...@intel.com: > Hi, > > It happened to me a couple of times in the past and again today. I got > a V-1 on <https://review.coreboot.org/c/coreboot/+/77560> without any > "good reasons" as <https://qa.coreboot.org/job/coreboot-gerrit/244243/console> > error seems to be unrelated to my patch. > > Is there a way to restart the build and get rid of the V-1 without > re-submitting a patch with a minor commit message change ? > > Regards, > > -- > *Jeremy* > /One Emacs to rule them all/ > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes
Hi Hannah, Thanks for the update. Presumably the HDMI source isn't required in the uGOP driver for chromebooks, so that shouldn't be a problem. With chromebooks, only the eDP should need to be initialized to show signs-of-life. I guess the only thing I really see happening at this point is for Intel to make the uGOP driver a part of the FSP, which I understand isn't ideal. I'm sure you can understand that as an open source project, we've had enough proprietary blobs forced on the project already and don't want any more. Martin Sep 6, 2023, 10:58 by hannah.willi...@intel.com: > Here are the reasons why we cannot open source Meteor Lake uGOP: > - It has licensed code for HDMI and other industry specifications (i915 also > cannot open source HDMI 2.1) > - VBT spec is not open sourced > There will have to be a re-design of the uGOP component so that we can work > around above issues and still open source. This is being considered for > future SOCs. > Hannah > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] x86: Add .data section support for pre-RAM stages
Hi Jeremy, I've added it to the agenda for today's leadership meeting. Martin Sep 5, 2023, 15:30 by jeremy.composte...@intel.com: > Hi, > > Any feedback on this topic ? > > I made some significant changes and made sure to cover all the cases > we identified including non-XIP stages. Cf. > <https://review.coreboot.org/q/topic:x86-pre-ram-data-section> > > Thanks, > Jeremy > > "Compostella, Jeremy" writes: > >> Dear coreboot community, >> >> I am looking for feedback on the following topic. >> >> x86 Pre-memory stages do not support the `.data' section and as a result >> developers are required to include runtime initialization code instead >> of relying on C global variable definition. >> >> To illustrate the impact of this lack of .data section support, here >> are two limitations I personally ran into: >> 1. The inclusion of libgfxinit in romstage last year has required some >> changes in libgfxinit to ensure data is initialized at runtime. In >> addition, we had to manually map some .data symbols in the _bss >> region. >> 2. CBFS cache is currently not supported in pre-memory stages and >> enabling it would require to add an initialization function and >> find a generic spot to call it. >> >> Instead of going though these workarounds and as it was suggested on >> [[RFC] VGA Text mode in romstage] last year, I believe we could add >> support for a `.data' section. I have been working on a solution for >> eXecute-In-Place (XIP) pre-memory stages (`bootblock', `verstage' and >> `romstage') which deliver good results >> (cf. <https://review.coreboot.org/c/coreboot/+/77289>). >> >> In short this patch: >> 1. creates a new ELF segment to hold the `.data' section >> 2. creates a `.data' section with its Virtual Memory Address (VMA) >> within Cache-as-RAM (CAR) boundaries and its Load Memory Address >> (LMA) following the .text section (at `_etext'). >> >> cbfstools is also updated: >> - To process this new segment and `.data' section >> - To place the .data section content right after the >> code (cf. `parse_elf_to_xip_stage' function) >> >> At the moment, this patch makes cbfstool detects the presence of the >> segment automatically and assume this is a "data" segment. But we >> could add a new parameter to make this new behavior less automatic if >> you think this would be better. >> >> This patch also adds a piece of assembly code (or C-code for >> bootblock) to copy the `.data' section content to Cache-As-RAM at >> runtime. >> >> Regards, >> > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
Hi Jeremy and all the rest of the Intel folk who took the time to come to the coreboot meeting today. I wasn't thrilled with the message you were there to present, but I was happy to see all who attended. I may be incorrect, but I assume that Google has been talking with Intel about displaying a screen during memory training for roughly the same amount of time that it's been discussed with AMD. For us, I believe that discussion started well over a year ago. For this to be brought up now, with the argument of "Well, we need it for this coming platform" seems like a problem brought on by not having this discussion with the coreboot community much earlier in the process. The urgency of getting a solution merged at this point is not coreboot's doing or responsibility, and it seems like coreboot is being pressured to accept it based on the timing, which doesn't feel great. The argument of "we'd like one solution for both coreboot and UEFI firmware" seems reasonable to me, but there seems to have been little attention paid to what coreboot, an open source project, actually wants. Instead, the position seems to be one of forcing coreboot to use what the UEFI firmware uses. I don't like that idea, but as was said in the meeting today, coreboot is willing to accept that, but on the condition that the source for the binary (and future similar binaries) is made open. To show good faith Intel could guarantee that the source will be opened when it can (supplying a date) and release the GOP driver source for platforms that do have released PRMs. You say here that the uGOP functionality already exists in the FSP, but since it's a proprietary blob, I can't actually *tell* what's in there (not that I'm doubting your word). This argument is also one of "What's the harm in just one more blob?" which has no reason to ever end. At some point, we need to say "no more". This seems like a reasonable time. I understand why companies feel like they need to keep some things proprietary, even if I don't like it. This blob just doesn't feel like one of those things. This feels like something that could be opened, Intel just can't be bothered to do the work to open it, at least not in a timely manner. Someone inside Intel has the authority to open source this binary. Someone can get the programmer manual released. If this is an important feature for this Chromebook, surely that person will decide that it makes sense to open source it so that it can be used with coreboot. If they decide it's not important enough, that's fine too. Apologies again to all the engineers who are stuck in the middle here. I'll buy a round of drinks if I see you at the Open Source Firmware Conference in October. Martin Aug 23, 2023, 16:25 by jeremy.composte...@intel.com: >> Hi Jeremy, >> >> Thanks for posting this. I know that you're planning on doing a >> presentation about this in this week's leadership meeting and look >> forward to that. <https://coreboot.org/calendar.html> >> >> A few questions: >> 1) How does the uGOP driver work with libgfxinit? Does using uGOP mean >> that the full GOP driver then needs to be used, or can the system >> transition back to libgfxinit after memory is initialized. >> > > uGOP does not interact with libgfxinit. However, even though we could > not test it, there is no reason to think libgfxinit would not work > properly if run after uGOP. > >> 2) When is the Graphics Programmer Reference Manuals going to be >> published so that the support can be added? Is this planned for next >> month, next year, or not currently planned, but hoped for? >> > > We do not have a clear commitment that the Meteor Lake Programmer > Manual are going to published publicly. i915 public driver code can be > used as a reference once it fully supports Meteor Lake graphics > generation. > >> 3) Is there a reason that the uGOP driver can't be open sourced, at >> least once the Graphics Programmer Reference Manuals are released? >> > > We cannot open-source the code for platforms for which the PRMs are > not publicly published and we currently do not have a commitment for > having RPMs for Meteor Lake. > >> 4) When you talk about the differences in time between the uGOP driver >> and libgfxinit, is that strictly due to when they are called, or is >> there some further difference that the uGOP driver is able to >> accomplish that libgfxinit wouldn't ever be able to do? >> > > This is not due to the way they are being called. We have not > investigated the reasons behind why uGOP and GOP also are faster to > bring up graphics. This is just an observation. > >> 5) Is there a reason that Intel is unwilling to add (or help add) the >> require
[coreboot] Re: [RFC] Pre-Memory Sign-of-Life using Intel uGOP
Hi Jeremy,
Thanks for posting this. I know that you're planning on doing a presentation
about this in this week's leadership meeting and look forward to that.
https://coreboot.org/calendar.html
A few questions:
1) How does the uGOP driver work with libgfxinit? Does using uGOP mean that the
full GOP driver then needs to be used, or can the system transition back to
libgfxinit after memory is initialized.
2) When is the Graphics Programmer Reference Manuals going to be published so
that the support can be added? Is this planned for next month, next year, or
not currently planned, but hoped for?
3) Is there a reason that the uGOP driver can't be open sourced, at least once
the Graphics Programmer Reference Manuals are released?
4) When you talk about the differences in time between the uGOP driver and
libgfxinit, is that strictly due to when they are called, or is there some
further difference that the uGOP driver is able to accomplish that libgfxinit
wouldn't ever be able to do?
5) Is there a reason that Intel is unwilling to add (or help add) the required
code to libgfxinit, an open source solution that according to your notes should
be comparable to the uGOP binary solution? Would Intel be willing to help once
the reference manuals are released, or is any cooperation between intel and the
community on libgfxinit just not able to happen?
6) I assume that the uGOP driver is completely optional, and is only needed to
show early signs of life. Is that correct, or could the uGOP driver become
mandatory at some point?
Please understand that any unhappiness about this plan is not directed at you
personally (or *should* not be), but just the idea of adding yet another binary
blob to the coreboot boot flow. I've been in this same spot and understand the
frustration of just trying to get your work done, while the community is
unhappy about the direction of the work being done.
Thanks very much.
Martin
Aug 14, 2023, 14:53 by jeremy.composte...@intel.com:
>
> Dear coreboot developers,
>
>
> With Raptor Lake, we introduced the Pre-Memory Sign-of-Life feature which
> displays an on-screen message while firmware components such as coreboot,
> Firmware Support Package Memory (FSP-M) or, CSME perform long time operations
> during pre-memory stages.
>
>
> We propose to take advantage of a proprietary driver Intel already supports,
> validates and includes in FSP silicon: the Intel Graphics PEIM (Pre-EFI
> Initialization Module) driver also known as the GOP (Graphical Output
> Protocol) driver.
>
>
> This driver is designed to run in post-memory initialization stages.
> Therefore, we derived a new version capable of running in pre-memory stages
> which we called µGOP. This version is specifically designed to perform
> graphics legacy VGA initialization.
>
>
> We intend to keep providing such a binary base solution on the long run as it
> addresses our software convergence goals and is compatible with early
> platform development stage constraints. > libgfxinit
> <https://github.com/coreboot/libgfxinit>> supports can always be added later
> by the open-source community once the Graphics Programmer Reference Manuals
> are published.
>
>
> Below, we present the work we performed to run this µGOP driver from coreboot
> romstage. It allows to initialize graphics with a very similar flow compared
> to > libgfxinit <https://github.com/coreboot/libgfxinit>> use.
>
>
> Our goal is to start collecting feedback. We will release all the patches on
> coreboot.org under the > ugop <https://review.coreboot.org/q/topic:ugop>>
> topic soon.
>
> 1.> µGOP driver interface
>
> The uGOP PEIM provides the following PEIM-to-PEIM protocol under the >
> 31a4622d-0e21-40a2-80db-c44208fce1b5> GUID.
>
> #define> > PEI_PREMEM_GRAPHICS_PPI_GUID> \{ \ 0x31a4622d, 0x0e21, 0x40a2,
> 0x80, 0xdb, 0xc4, 0x42, 0x08, 0xfc, 0xe1, 0xb5 \};
>
> The protocol is composed of three fields.
>
> struct> { > UINT32> > Version> ; >
> PREMEM_PEI_GRAPHICS_INIT> > PreMemGraphicsPpiInit> ; >
> PREMEM_PEI_GRAPHICS_EXIT> > PreMemGraphicsPpiExit> ;} >
> PEI_MICRO_GRAPHICS_PPI> ;
> The current > Version> is > 0x0001> . Where the upper 16 bits represent
> the major (1) and the lower 16 bits represent the minor number.
>
> PreMemGraphicsPpiInit()
>
> typedef> EFI_STATUS> (> EFIAPI> *> PREMEM_PEI_GRAPHICS_INIT> ) ( IN >
> VOID> *> Vbt> );
>
> The > PreMemGraphicsPpiInit()> should be supplied with a pointer to the
> Video BIOS Table.
>
> PreMemGraphicsPpiExit()> does not take any parameters. This function must be
> called to disable V
[coreboot] [coreboot - Bug #496] Missing malloc check in libpayload
Issue #496 has been updated by Martin Roth.
Category set to Payloads
Bug #496: Missing malloc check in libpayload
https://ticket.coreboot.org/issues/496#change-1629
* Author: Keith Makan
* Status: New
* Priority: Normal
* Category: Payloads
* Target version: none
* Start date: 2023-06-27
* Affected versions: 4.21
* Affected hardware: ALL
* Affected OS: ALL
libpayload in payload/libpayload/drivers/options.c::get_option_as_string does
not issue a NULL check against malloc's return code.
Should there be a NOMEM error this may result in a NULL pointer deref or crash.
The following code extract illustrates the mentioned issue:
`
int get_option_as_string(const struct nvram_accessor *nvram, struct
cb_cmos_option_table *option_table, char **dest, const char *name)
{
...
/* extra byte to ensure 0-terminated strings */
raw = malloc(cmos_length+1);
memset(raw, 0, cmos_length+1); <--- no check against malloc's return
code
`
--
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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #495] (Resolved) Stoney chromebooks not booting PSPSecureOS -- Graphics driver takes 30 minutes to start
Issue #495 has been updated by Martin Roth. Subject changed from Stoney not booting PSPSecureOS -- Graphics driver takes 30 minutes to start to Stoney chromebooks not booting PSPSecureOS -- Graphics driver takes 30 minutes to start Status changed from Response Needed to Resolved Patch was merged 2 months ago and there has been no further update. Marking as resolved. Bug #495: Stoney chromebooks not booting PSPSecureOS -- Graphics driver takes 30 minutes to start https://ticket.coreboot.org/issues/495#change-1628 * Author: CoolStar Organization * Status: Resolved * Priority: High * Category: chipset configuration * Target version: none * Start date: 2023-06-14 * Affected versions: 4.21, 4.15, 4.16, 4.17, 4.18, 4.19, master * Affected hardware: stoney * Affected OS: Windows 10, Windows 11 Windows 11 Graphics driver takes 30 minutes to start on Stoney due to missing PSPSecureOS. Windows 10 20H2 and newer hangs on boot (potentially from the same thing) -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Run abuild only on sandybridge boards with MRC raminit. How?
Hi Keith, Sorry about the late reply here. Responses inline: Jul 25, 2023, 22:25 by buu...@gmail.com: > After 34 patches converting all sandybridge boards to Haswell-style > SPD info, I now need to run abuild to see if I missed any, To save > time, space, and possibly wear on my SSD I only want to run abuild on > sandybridge boards (i.e. boards with NORTHBRIDGE_INTEL_SANDYBRIDGE > Kconfig) and, for boards that don't force USE_NATIVE_RAMINIT, run it > with that Kconfig off. > > I ran this from my mechanical USB drive: > $ util/abuild/abuild --timeless --skip_unset > NORTHBRIDGE_INTEL_SANDYBRIDGE -R /usr/src/coreboot > > And all boards get skipped. It seems right, until I saw these two > known SNB boards getting skipped too, then I stopped the run. > > Building board INTEL_DQ67SW (using default config) > Building INTEL_DQ67SW > Creating config file for INTEL_DQ67SW... > INTEL_DQ67SW (Skipping CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE not set) > INTEL_DQ67SW config created. > config file: coreboot-builds/INTEL_DQ67SW/config.build has incorrect > config value > INTEL_DQ67SW does not have NORTHBRIDGE_INTEL_SANDYBRIDGE set. Skipping > at user's request. > Building board INTEL_EMERALDLAKE2 (using default config) > Building INTEL_EMERALDLAKE2 > Creating config file for INTEL_EMERALDLAKE2... > INTEL_EMERALDLAKE2 (Skipping CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE not set) > INTEL_EMERALDLAKE2 config created. > config file: coreboot-builds/INTEL_EMERALDLAKE2/config.build has > incorrect config value > INTEL_EMERALDLAKE2 does not have NORTHBRIDGE_INTEL_SANDYBRIDGE set. > Skipping at user's request. > > Is what I did supposed to work? > Yes, that command line looks reasonable and actually works for me though for some reason it still says it's skipping it. I'll look at what the issue is there. Thanks for bringing this to my attention. ``` Building APPLE_MACBOOKAIR4_2 Creating config file for APPLE_MACBOOKAIR4_2... APPLE_MACBOOKAIR4_2 (Skipping CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE not set) APPLE_MACBOOKAIR4_2 config created. Compiling APPLE_MACBOOKAIR4_2 image... APPLE_MACBOOKAIR4_2 built successfully. (took 34.356 seconds) ``` In the meantime, I added a script a little while back to do exactly what you want: util/scripts/testsoc ``` testsoc version 1.00 The testsoc script helps select boards to run test builds on. It searches through all of the mainboard Kconfig files for specified identifiers and then runs abuild on the mainboards it finds. Usage: testsoc [options] Options: -a | --abuild "" Specify options to pass to abuild -C | --cpus Specify number of CPUs to use -K | --kconfig Search for Kconfig option (-K can be used multiple times) -n | --no_cros Don't run chromeos builds -h | --help Print usage and exit -D | --debug Print debug information. Use -DD to show all commands -V | --version Print the version and exit --nocolor Don't print color codes ``` Here's the command line you'd want. util/scripts/testsoc -K NORTHBRIDGE_INTEL_SANDYBRIDGE > For the second item about USE_NATIVE_RAMINIT, do I really have to set > a board config for each and every MRC raminit board and turn it off > there? > abuild lets you supply a saved config file to apply over the config normally used. This allows you to update settings. You should be able to make a config file with just the one setting CONFIG_USE_NATIVE_RAMINIT=y, then tell abuild to use that file with -K . for the testsoc script, that would look like: util/scripts/testsoc -K NORTHBRIDGE_INTEL_SANDYBRIDGE -a "-K " > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: switch or router hardware with coreboot
All, Cisco Meraki are possibly the most FOSS hostile vendor I have ever had the displeasure of trying to pry GPL source code from. It took Meraki more than 12 months to provide the coreboot source code for the MX84 and MX250, and that occurred only after we (the hardware owners) lost patience and threatened to escalate the matter to coreboot/FSF. I have currently been waiting over 8 months for the source code of another Meraki product (that does not utilize coreboot, so is of no concern to this mailing list). I would not recommend Cisco Meraki or their hardware to anyone interested in open-source firmware/devices. You will have a bad time. Regards, Hal On Fri, Jul 28, 2023 at 10:50 AM Zeh, Werner via coreboot wrote: > > Hi Carl-Daniel. > > We had an issue with Cisco Meraki last year (see [1]) where it turned out > that at least their MX84 and MX250 switches run with coreboot (looked like a > Broadwell-DE based design). > Maybe it is worth to have a closer look at their products for your use case. > > Werner > > [1] > https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/ONXER67WIFHDAOSAOK3PNPBJIMHFXC2P/ > > > -Original Message- > > From: Carl-Daniel Hailfinger > > Sent: Tuesday, July 25, 2023 6:54 PM > > To: Coreboot > > Subject: [coreboot] switch or router hardware with coreboot > > > > Hi, > > > > is there any currently commercially available switch or router hardware > > (10Gbit/s or more) running coreboot and preferably also Linux? > > > > I'm currently trying to build a PoC network where all components have > > mostly FOSS firmware and operating systems. > > > > My Wifi access points and 1 Gbit/s switches are running U-Boot and > > OpenWrt, so on that tier I'm covered. OpenWrt is even running on very few > > select 10 Gbit/s switches, but there the bootloader seems to be > > U-Boot+blob. > > For routing, I'm currently using PCEngines APU2 with coreboot and Debian, > > but those are not really made to handle routing or even NAT at more than 1 > > Gbit/s. > > > > Once the PoC phase is done, I expect required routing/NAT/packet filtering > > bandwidth to exceed 5 Gbit/s and I'd like to use a coreboot based product > > for that. > > If necessary, I can add a few network cards to a general-purpose server, but > > a purpose-built device would be preferred. > > > > Suggestions? Comments? > > > > Thanks, > > Carl-Daniel > > ___ > > coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email > > to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #500] coreboot bootsplash only supports jpeg and does not support extended resolutions
Issue #500 has been updated by Martin Roth. Tracker changed from Bug to Feature Assignee deleted (Patrick Georgi) Changing to a feature request and unassigning from Patrick. I believe this is currently working as designed. It could definitely be extended, but I don't believe that the lack of those features should be considered a "bug". If anyone wants to take on this work, please feel free to assign it to yourself. Feature #500: coreboot bootsplash only supports jpeg and does not support extended resolutions https://ticket.coreboot.org/issues/500#change-1607 * Author: Thierry Laurion * Status: New * Priority: Normal * Category: coreboot common code * Target version: master * Start date: 2023-07-13 * Related links: https://github.com/coreboot/coreboot/blob/master/src/lib/jpeg.c https://git.seabios.org/seabios.git/ https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3#diff-816b79cd9a1192fa8cf78b9737f0d3fed5a943a0d2c952da591f8a2446edc1db WiP PoC: https://github.com/osresearch/heads/pull/1403 * Affected hardware: All using coreboot display init + bootsplash * Affected OS: n/a For those of you on matrix, the discussion happened at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat=matrix.org=matrix.zerodao.gg Short version: - libgfxinit bootsplash through jpeg.c supports VESA old resolutions (1024x768) - libgfxinit bootsplash through jpeg.c doesn't support native resolutions (1366x768) - libgfxinit bootsplash image creation requires voodoo skills explained at https://puri.sm/posts/librem-13-coreboot-report-february-25th-2017 - Basically, I do not think libgfxinit bootsplash is currently used otherwise there would be way more bug reports. Seabios is mostly used. - Seabios bootsplash code should be borrowed (lgplv3) which supports both BMP and JPEG and is not 13yo. - Coreboot should permit stiching of compressed bmp by default and deprecate old jpeg.c in tree - By doing so, more people could promote coreboot directly from coreboot raminit (Heads currently does that) Longer version: - OSes are attacking legacy BIOS mode for a while now, and the next steps are to deprecate DRM drivers in initrd - To phase DRM out, simplefb and simpledrm are promoted instead where final OS will be in charge of deploying bigger unified kernels containing/initrd which will contain the accelerated DRM and fb drivers - Currently deploying DRM drivers inside of linuxboot (heads) on Intel iGPU requires to include i915drmfb, coreboot linux command lines hacks to have the FB address exposed (tainting the kernel) and kexec hacked to expose exposed fb address to next kernel (see https://github.com/osresearch/heads/pull/1378) - Doing currently adds more then 500kb of in-kernel drivers, which bloats the firmware. In case of measured boot, that bigger payload needs to be measured prior of being read and jumped into (8-10 seconds under 5.10 kernel compared to 4-6 seconds under 4.14) - To have legacy BIOS survive this ecosystem attack against legacy boot, coreboot needs to push for a more generic way to provide a framebuffer (GOP/Native unified approach) - With libgfxinit/GOP/native gfx init and the kernel config adapted, linux can efficiently be used as a bootloader and be enabled by simplefb (https://github.com/osresearch/heads/pull/1403/commits/659308eff53f39633ffad71597a2463fa30eedd3) - The part missing is having coreboot drive the framebuffer with a native size bootsplash as everyone else does so that the waiting time to boot in kernel/payload is not a scary moment, and that the bootsplash doesn't restrict the size of the framebuffer configured under coreboot nor limit the UX. Actual state: - libgfxinit needs to have jpeg supported resolution to bootsplash (CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024) - libgfxinit bootsplash needs to have a 1024x768 voodoo crafted jpeg (https://github.com/osresearch/heads/blob/master/blobs/ThePlexus-bootsplash-1024x768.jpg) - Problem is that doing so, the whole console is limited to that resolution showing black borders on each side of the screen to compensate (1366 != 1024, so (1366-1024)/2 is the loss pixel width on each side of the screen for 1366x764, same applying to all other resolutions since needs to be 4x4 for jpeg.c to do its job. Desired state: - flat bmp support in native format just like seabios support, where coreboot compressed them prior of adding it into CBFS. - support for all crazy resolutions we currently have, not being stuck in 2000. - Be able to promote coreboot from raminit code. ---Files signal-2023-07-13-164022.jpeg (269 KB) signal-2023-07-13-164047.jpeg (416 KB) VID_20230713_154446.mp4 (3.78 MB) signal-2023-07-13-171757.jpeg (275 KB) signal-2023-07-13-171801
[coreboot] Re: How to best handle new Intel Saphire Rapids server boards based on Intel Archer City?
Duplicated code between mainboards isn't a big issue in my opinion. It allows the boards to be customized without worrying about other companies' mainboards. We've tried to make mainboards as small as we can, and we can keep refactoring things out where it makes sense. If some common code fits under the SoC, that's great, and I'm all for moving it there, but let's not force the burden of that refactoring work onto inexperienced mainboard maintainers. Doing so just encourages vendors to keep their mainboards in private repositories - the opposite of what we should be working for. Even if this means that it doesn't get refactored and gets a bit out-of-date, I find that preferable to making contributors (more) frustrated about getting their boards accepted. CRBs are (as the name says) reference boards and it should be absolutely fine to duplicate their code when another mainboard vendor uses the CRB as their base - that's what the CRB is for - as an example. Forcing the board to be under the intel vendor directory tells me that intel is responsible for the board, when that isn't the case. In my opinion, Mainboards should be free to customize anything and everything in their directories without having to worry about what other mainboards are affected. I think for the most part, variants should be reserved for duplicates that are owned/maintained by the same vendor. Whitelabel vendors like Clevo can be an exception to this, but the chip vendors' CRBs should not be forced as a baseboard for some other company's design. Respectfully,Martin Jun 19, 2023, 07:08 by th3fan...@gmail.com: > Hi Paul, list, > > On Thu, Jun 8, 2023, 16:16 Paul Menzel <> pmen...@molgen.mpg.de> > wrote: > >> [Annie, Yiwei, I only added you to Cc. It’d be great if you made sure >> that all involved people are subscribed to the coreboot mailing list.] >> >> Dear coreboot folks, >> >> >> Two server boards based on Intel Archer City board, commit 30e743e7cc7f >> (mb/ibm: Add 4 SPR sockets server board IBM SBP1) [1], were pushed to >> Gerrit for review: >> >> 1. mb/inventec: Add Intel SPR server board Inventec Transformers [2] >> Change-Id: Ic9d99c3aadaa9f69e6d14d4b1a6c5157f5590684 >> 2. bytedance/bd_egs (Eaglestream) [3] >> Change-Id: I091bc78e39cd76b3c6b9a10a1fcf58e9d671ef5d >> >> Some code seems to be copied – like bootblock.c [4] – and almost >> identical to the reference platform. To avoid future maintenance burden, >> could more knowledgeable people comment, if server boards differ >> drastically so separate boards are justified or if they should be made >> variants. >> > > A variant setup with boards from different vendors sounds like a maintenance > nightmare. We still have a common place to put the redundant code, though: in > chipset (SoC) code. The bootblock LPC decode can definitely be factored out. > > That being said, it may be easier to factor things out after these three > board ports have been submitted. The boot > > >> I also noticed `mainboard_config_iio()`. Should that be moved to the >> devicetree? >> > > If the settings are only used in ramstage (where the devicetree is R/W), they > could be moved to the devicetree. However, if these settings are used in > romstage, the devicetree would negatively impact runtime-dependent > configuration (e.g. when using straps to control IIO bifurcation depending on > slot occupancy), as the devicetree cannot be updated at runtime in romstage > (or earlier). > > >> Kind regards, >> >> Paul >> >> >> [1]: >> https://review.coreboot.org/c/coreboot/+/73392 >> "mb/ibm: Add 4 SPR sockets server board IBM SBP1" >> [2]: >> https://review.coreboot.org/c/coreboot/+/75598 >> "mb/inventec: Add Intel SPR server board Inventec Transformers" >> [3]: >> https://review.coreboot.org/c/coreboot/+/75722 >> "mb/bytedance: Add 2 SPR sockets server board bd_egs" >> [4]: >> >> >> https://review.coreboot.org/c/coreboot/+/75598/5/src/mainboard/inventec/transformers/bootblock.c#18 >> ___ >> coreboot mailing list -- >> coreboot@coreboot.org >> To unsubscribe send an email to >> coreboot-le...@coreboot.org >> > > Best regards, > Angel > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #462] Sandy Bridge Raminit failure, only half of the memory modules initialized.
Issue #462 has been updated by Martin Roth. Are you sure the 2nd DIMM is working? Since one of the two DIMMs works and the other doesn't, it seems suspicious. You might also want to try clearing the MRC Cache area. Your first boot log said that it was trying stored timings, and those might not work with the 2nd DIMM. Bug #462: Sandy Bridge Raminit failure, only half of the memory modules initialized. https://ticket.coreboot.org/issues/462#change-1433 * Author: shen Liu * Status: New * Priority: Normal * Category: infrastructure * Target version: master * Start date: 2023-02-16 * Affected versions: master * Needs backport to: master ``` shell sudo dmidecode -t 17 # dmidecode 3.4 Getting SMBIOS data from sysfs. SMBIOS 3.3.0 present. Handle 0x000A, DMI type 17, 40 bytes Memory Device Array Handle: 0x0009 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 8 GB Form Factor: DIMM Set: None Locator: Channel-0-DIMM-0 Bank Locator: BANK 0 Type: DDR3 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 800 MT/s Manufacturer: Unknown (1383) Serial Number: 02a0 Asset Tag: Channel-0-DIMM-0-AssetTag Part Number: CL11-11-11 D3-16 Rank: 2 Configured Memory Speed: 800 MT/s Minimum Voltage: Unknown Maximum Voltage: Unknown Configured Voltage: Unknown ``` ``` shell NOTE ] coreboot-4.19-424-geba1a35402-dirty Sun Feb 12 10:30:43 UTC 2023 x86_32 bootblock starting (log level: 7)... [DEBUG] FMAP: Found "FLASH" version 1.1 at 0xe5. [DEBUG] FMAP: base = 0xff00 size = 0x100 #areas = 5 [DEBUG] FMAP: area COREBOOT found @ e50200 (1768960 bytes) [INFO ] CBFS: mcache @0xfeff0e00 built for 12 files, used 0x2ac of 0x4000 bytes [INFO ] CBFS: Found 'fallback/romstage' @0x80 size 0x180f8 in mcache @0xfeff0e2c [DEBUG] BS: bootblock times (exec / console): total (unknown) / 45 ms [NOTE ] coreboot-4.19-424-geba1a35402-dirty Sun Feb 12 10:30:43 UTC 2023 x86_32 romstage starting (log level: 7)... [DEBUG] SMBus controller enabled [DEBUG] Setting up static northbridge registers... done [DEBUG] Initializing Graphics... [DEBUG] Back from systemagent_early_init() [INFO ] Intel ME early init [INFO ] Intel ME firmware is ready [DEBUG] ME: Requested 0MB UMA [DEBUG] Starting native Platform init [DEBUG] DMI: Running at X4 @ 5000MT/s [DEBUG] FMAP: area RW_MRC_CACHE found @ e0 (65536 bytes) [DEBUG] Trying stored timings. [DEBUG] Starting Ivy Bridge RAM training (fast boot). [DEBUG] 100MHz reference clock support: yes [DEBUG] PLL_REF100_CFG value: 0x2 [DEBUG] Trying CAS 11, tCK 320. [DEBUG] Found compatible clock, CAS pair. [DEBUG] Selected DRAM frequency: 800 MHz [DEBUG] Selected CAS latency : 11T [DEBUG] MPLL busy... done in 10 us [DEBUG] MPLL frequency is set at : 800 MHz [DEBUG] XOVER CLK [c14] = 300 [DEBUG] XOVER CMD [320c] = 24000 [DEBUG] XOVER CLK [d14] = 0 [DEBUG] XOVER CMD [330c] = 4000 [DEBUG] DBP [4000] = 1c [DEBUG] RAP [4004] = cc187476 [DEBUG] OTHP [400c] = 68b4 [DEBUG] OTHP [400c] = 68b4 [DEBUG] REFI [4298] = 6cf01860 [DEBUG] SRFTP [42a4] = 41f88200 [DEBUG] DBP [4400] = 1c [DEBUG] RAP [4404] = cc187476 [DEBUG] OTHP [440c] = 68b4 [DEBUG] OTHP [440c] = 68b4 [DEBUG] REFI [4698] = 6cf01860 [DEBUG] SRFTP [46a4] = 41f88200 [DEBUG] Done dimm mapping [DEBUG] Update PCI-E configuration space: [DEBUG] PCI(0, 0, 0)[a0] = 0 [DEBUG] PCI(0, 0, 0)[a4] = 2 [DEBUG] PCI(0, 0, 0)[bc] = 82a0 [DEBUG] PCI(0, 0, 0)[a8] = 7d60 [DEBUG] PCI(0, 0, 0)[ac] = 2 [DEBUG] PCI(0, 0, 0)[b8] = 8000 [DEBUG] PCI(0, 0, 0)[b0] = 80a0 [DEBUG] PCI(0, 0, 0)[b4] = 8080 [DEBUG] Done memory map [DEBUG] RCOMP...done [DEBUG] COMP2 done [DEBUG] COMP1 done [DEBUG] FORCE RCOMP and wait 20us...done [DEBUG] Done io registers [DEBUG] CPE [DEBUG] CP5b [DEBUG] CP5c [DEBUG] OTHP [400c] = 68b4 [DEBUG] t123: 1767, 6000, 7620 [NOTE ] ME: Wrong mode : 2 [NOTE ] ME: FWS2: 0x160a0140 [NOTE ] ME: Bist in progress: 0x0 [NOTE ] ME: ICC Status : 0x0 [NOTE ] ME: Invoke MEBx : 0x0 [NOTE ] ME: CPU replaced: 0x0 [NOTE ] ME: MBP ready : 0x0 [NOTE ] ME: MFS failure : 0x1 [NOTE ] ME: Warm reset req : 0x0 [NOTE ] ME: CPU repl valid : 0x1 [NOTE ] ME: (Reserved) : 0x0 [NOTE ] ME: FW update req : 0x0 [NOTE ] ME: (Reserved) : 0x0 [NOTE ] ME: Current state : 0xa [NOTE ] ME: Current PM event: 0x6 [NOTE ] ME: Progress code : 0x1 [NOTE ] PASSED! Tell ME that DRAM is ready [NOTE ] ME: ME is reporting as disabled, so not waiting for a response. [NOTE ] ME: FWS2: 0x160a0140 [NOTE ]
[coreboot] [coreboot - Bug #455] superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D
Issue #455 has been updated by Martin Roth. Subject changed from superiotool recognizes the wrong chip and doesn't work. to superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D Bug #455: superiotool detects Aspeed AST2400 instead of Nuvoton NCT6779D https://ticket.coreboot.org/issues/455#change-1426 * Author: shen Liu * Status: New * Priority: Normal * Category: userspace utilities * Target version: master * Start date: 2023-02-07 * Affected versions: master * Needs backport to: none * Related links: More discussion： https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_supported_by_coreboot/ https://wiki.archlinux.org/title/Debuginfod * Affected hardware: MSI B85M-E45 * Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1) ``` shell sudo ./superiotool Found Aspeed AST2400 (id=0x00) at 0x4e sudo ./superiotool superiotool r4.19-306-g12ec7901b7 No Super I/O found ``` Does superiotool provide debug symbols? Without debug symbols I can't use gdb to provide more useful information. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #456] coreboot 4.19 tarballs have bad timestamps
Issue #456 has been updated by Martin Roth. Hashes for all of the tarballs, old and new have been added to the bottom of the release notes. Hashes for tarballs & signatures Old tarballs: - a1f9ec1252a3cc19f0b4ba1a2b9d66ea9327499cbeecebd85377db7d5c68555d coreboot-4.19.tar.xz - 6ceaa39429a2094d75e4c8a94615ae60664ddad7b4115570b65b9bb516cbd96d coreboot-4.19.tar.xz.sig - 881a3477221d1b77e161759344df14eccda115086af3ef54e66485ae0eb2e5d9 coreboot-blobs-4.19.tar.xz - 16f4f1f7acc6203ce915ffea64edce8512bd9eb9e94e65db22a0cb5282a6e157 coreboot-blobs-4.19.tar.xz.sig New tarballs: - 65ccb2f46535b996e0066a1b76f81c8cf1ff3e27df84b3f97d8ad7b3e7cf0a43 coreboot-4.19.tar.xz - d3c52a209b8ccb49049960318f04f158dd47db52ebe6019d6a3dffe3196d9cbe coreboot-4.19.tar.xz.sig - 30214caed07b25f11e47bec022ff6234841376e36689eb674de2330a3e980cbc coreboot-blobs-4.19.tar.xz - 023d511d074703beab98c237c3e964dc7c598af86d5a0e2091195c68980b6c5d coreboot-blobs-4.19.tar.xz.sig Bug #456: coreboot 4.19 tarballs have bad timestamps https://ticket.coreboot.org/issues/456#change-1407 * Author: Thierry Laurion * Status: Feedback * Priority: High * Category: infrastructure * Target version: 4.19 * Start date: 2023-02-08 * Affected versions: 4.19, master * Needs backport to: 4.19, master * Related links: Thank you for the fixes. Could you document the old and new hashes somewhere? As reported on #coreboot channel, coreboot 4.19 tarballs contain invalid timestamps (year 1901) for all contained files. Reproducility of issue: wget https://www.coreboot.org/releases/coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ ls -al coreboot-4.19.tar.xz -rw-r--r-- 1 user user 56908588 Jan 26 21:46 coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ tar Jxvf coreboot-4.19.tar.xz coreboot-4.19/ coreboot-4.19/.checkpatch.conf tar: coreboot-4.19/.checkpatch.conf: implausibly old time stamp -9223372036854775808 coreboot-4.19/.clang-format tar: coreboot-4.19/.clang-format: implausibly old time stamp -9223372036854775808 coreboot-4.19/.coreboot-version tar: coreboot-4.19/.coreboot-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.crossgcc-version tar: coreboot-4.19/.crossgcc-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.editorconfig tar: coreboot-4.19/.editorconfig: implausibly old time stamp -9223372036854775808 Cause: @icon investigated and said "d05ea79e40c4 util/release/build-release: Fix style issues at least that change to the tstamp variable looks very suspicious" flx suggested to recreate the archive: "I think 4.19-2 would be better. There are no changes to coreboot or anything. It also doesn't need a new git tag" -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #456] (Feedback) coreboot 4.19 tarballs have bad timestamps
Issue #456 has been updated by Martin Roth. Status changed from New to Feedback New 4.19 tarballs have been pushed, but they use the same name. I updated the release notes stating that they had been updated. I looked at changing the name, but to do that, the actual release number needs to be changed on the website. The names are tightly coupled. Since this is still the 4.19 release, just a repack of the tarballs, the names needed to remain the same. I felt that changing the release name would create more long-term confusion, so at least for now, the binaries are posted with the same name. I have preserved the old binaries, but moved them out of the download folder. Let me know if this is a satisfactory resolution. I'll mark this issue fixed after any further discussion or lack of discussion. Bug #456: coreboot 4.19 tarballs have bad timestamps https://ticket.coreboot.org/issues/456#change-1405 * Author: Thierry Laurion * Status: Feedback * Priority: High * Category: infrastructure * Target version: 4.19 * Start date: 2023-02-08 * Affected versions: 4.19, master * Needs backport to: 4.19, master As reported on #coreboot channel, coreboot 4.19 tarballs contain invalid timestamps (year 1901) for all contained files. Reproducility of issue: wget https://www.coreboot.org/releases/coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ ls -al coreboot-4.19.tar.xz -rw-r--r-- 1 user user 56908588 Jan 26 21:46 coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ tar Jxvf coreboot-4.19.tar.xz coreboot-4.19/ coreboot-4.19/.checkpatch.conf tar: coreboot-4.19/.checkpatch.conf: implausibly old time stamp -9223372036854775808 coreboot-4.19/.clang-format tar: coreboot-4.19/.clang-format: implausibly old time stamp -9223372036854775808 coreboot-4.19/.coreboot-version tar: coreboot-4.19/.coreboot-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.crossgcc-version tar: coreboot-4.19/.crossgcc-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.editorconfig tar: coreboot-4.19/.editorconfig: implausibly old time stamp -9223372036854775808 Cause: @icon investigated and said "d05ea79e40c4 util/release/build-release: Fix style issues at least that change to the tstamp variable looks very suspicious" flx suggested to recreate the archive: "I think 4.19-2 would be better. There are no changes to coreboot or anything. It also doesn't need a new git tag" -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #456] coreboot 4.19 tarballs have bad timestamps
Issue #456 has been updated by Martin Roth. I'll re-create the archive. I'd fixed the bug with the timestamps, but it must not have been included in the script that generated these tarballs. For naming, I'd rather not go with -2 unless we create a new tag. I think something like coreboot-4.19.fixed.tar.xz would be more appropriate. Bug #456: coreboot 4.19 tarballs have bad timestamps https://ticket.coreboot.org/issues/456#change-1403 * Author: Thierry Laurion * Status: New * Priority: High * Category: infrastructure * Target version: 4.19 * Start date: 2023-02-08 * Affected versions: 4.19, master * Needs backport to: 4.19, master As reported on #coreboot channel, coreboot 4.19 tarballs contain invalid timestamps (year 1901) for all contained files. Reproducility of issue: wget https://www.coreboot.org/releases/coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ ls -al coreboot-4.19.tar.xz -rw-r--r-- 1 user user 56908588 Jan 26 21:46 coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ tar Jxvf coreboot-4.19.tar.xz coreboot-4.19/ coreboot-4.19/.checkpatch.conf tar: coreboot-4.19/.checkpatch.conf: implausibly old time stamp -9223372036854775808 coreboot-4.19/.clang-format tar: coreboot-4.19/.clang-format: implausibly old time stamp -9223372036854775808 coreboot-4.19/.coreboot-version tar: coreboot-4.19/.coreboot-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.crossgcc-version tar: coreboot-4.19/.crossgcc-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.editorconfig tar: coreboot-4.19/.editorconfig: implausibly old time stamp -9223372036854775808 Cause: @icon investigated and said "d05ea79e40c4 util/release/build-release: Fix style issues at least that change to the tstamp variable looks very suspicious" flx suggested to recreate the archive: "I think 4.19-2 would be better. There are no changes to coreboot or anything. It also doesn't need a new git tag" -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #456] coreboot 4.19 tarballs have bad timestamps
Issue #456 has been updated by Martin Roth. Subject changed from coreboot 4.19 tarballs are unusable to coreboot 4.19 tarballs have bad timestamps Bug #456: coreboot 4.19 tarballs have bad timestamps https://ticket.coreboot.org/issues/456#change-1401 * Author: Thierry Laurion * Status: New * Priority: High * Category: infrastructure * Target version: 4.19 * Start date: 2023-02-08 * Affected versions: 4.19, master * Needs backport to: 4.19, master As reported on #coreboot channel, coreboot 4.19 tarballs contain invalid timestamps (year 1901) for all contained files. Reproducility of issue: wget https://www.coreboot.org/releases/coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ ls -al coreboot-4.19.tar.xz -rw-r--r-- 1 user user 56908588 Jan 26 21:46 coreboot-4.19.tar.xz user@heads-tests:/tmp/test$ tar Jxvf coreboot-4.19.tar.xz coreboot-4.19/ coreboot-4.19/.checkpatch.conf tar: coreboot-4.19/.checkpatch.conf: implausibly old time stamp -9223372036854775808 coreboot-4.19/.clang-format tar: coreboot-4.19/.clang-format: implausibly old time stamp -9223372036854775808 coreboot-4.19/.coreboot-version tar: coreboot-4.19/.coreboot-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.crossgcc-version tar: coreboot-4.19/.crossgcc-version: implausibly old time stamp -9223372036854775808 coreboot-4.19/.editorconfig tar: coreboot-4.19/.editorconfig: implausibly old time stamp -9223372036854775808 Cause: @icon investigated and said "d05ea79e40c4 util/release/build-release: Fix style issues at least that change to the tstamp variable looks very suspicious" flx suggested to recreate the archive: "I think 4.19-2 would be better. There are no changes to coreboot or anything. It also doesn't need a new git tag" -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Power button only works once - where to check for fixes (51nb X2100)?
Have you tested with a battery installed? I'm imagining a hardware glitch on shutdown that causes an EC failure. Many older desktop platforms wouldn't even power on if there wasn't a CMOS battery installed. Martin Jan 16, 2023, 11:08 by flyingfishfin...@gmail.com: > Morning, > Just checking in to see if anyone had some advice on where I could look to > try and fix this problem. Note that it also happens for sleep and suspend > modes, not just shutdowns. > > Thanks, > Rafael > > Am Do., 12. Jan. 2023 um 09:16 Uhr schrieb Rafael Send <> > flyingfishfin...@gmail.com> >: > >> Oh, there's not currently a battery installed - so that would do it. Thanks >> for a lead. >> >> What's the path to fixing that? Different EC blob extracted from stock BIOS, >> something in Coreboot to check? >> >> R >> >> Am Do., 12. Jan. 2023 um 09:11 Uhr schrieb Matt DeVillier <>> >> matt.devill...@gmail.com>> >: >> >>> sounds to me like AP shutdown is causing the EC to power off as well, so >>> it's not active to respond to the subsequent power button press. Not sure >>> why disconnecting AC power would reset that though, unless you are also >>> disconnecting the internal battery as well >>> >>> On Thu, Jan 12, 2023 at 11:08 AM Rafael Send <>>> >>> flyingfishfin...@gmail.com>>> > wrote: >>> >>>> Hi, >>>> As folks may have gathered from my other question about the GCC build >>>> environment, I've been playing around with the old X2100 port (>>>> >>>> https://github.com/mjg59/coreboot/tree/x2100_ng>>>> ). >>>> >>>> I got it to build and added the latest version of MrChromebox's Tianocore, >>>> but there's still one issue that keep is from being very useable. >>>> >>>> After flashing / plugging in the machine, the power button will turn it >>>> on, but only once. If I shut down any OS, or even if it goes to sleep or >>>> suspends, the power button no longer has any effect so the only "fix" is >>>> currently to unplug power and re-plug it. >>>> >>>> Where might I look for causes of this? Is it a shutdown state thing? ACPI? >>>> >>>> Thanks, >>>> Rafael >>>> ___ >>>> coreboot mailing list -- >>>> coreboot@coreboot.org >>>> To unsubscribe send an email to >>>> coreboot-le...@coreboot.org >>>> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #314] (Rejected) Please disable 'administrator approval' on ticket.coreboot.org
Issue #314 has been updated by Martin Roth. Status changed from New to Rejected Not a coreboot bug. closing Bug #314: Please disable 'administrator approval' on ticket.coreboot.org https://ticket.coreboot.org/issues/314#change-1373 * Author: akjuxr3 akjuxr3 * Status: Rejected * Priority: Normal * Category: infrastructure * Start date: 2021-07-30 Please disable this 'administrator approval' on ticket.coreboot.org. It feels like discrimination. Before i have written the first word on ticket.coreboot.org i have to be approved by someone by hand without this person knowing anything from me. I had to wait several days for this approval. Its completely unclear what is been tracked. Have the IP-address used for registration been tracked? Have the used email-address been tracked? E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! Username? Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. Conclusion: This 'administrator approval' is sort of discrimination i have not seen for years on free projects! There is no data available at the registration process that could or should be used to decide who is allowed to report a bug in the coreboot project. Please disable this discrimination that is stopping people for days or even forever to report a coreboot issue. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #326] (Closed) raminit fails after 58188 review.coreboot.org
Issue #326 has been updated by Martin Roth. Status changed from New to Closed No response to questions in the past year. Closing. Bug #326: raminit fails after 58188 review.coreboot.org https://ticket.coreboot.org/issues/326#change-1372 * Author: xinhua wang * Status: Closed * Priority: Normal * Start date: 2021-12-30 For this addition.. https://review.coreboot.org/c/coreboot/+/58188 What is the cause of this? ft232h log with raminit debug enabled https://pastebin.com/kHC0bXLs Read MPR training failed: 1, 2, 0 raminit failed If I remove the patches in here (top of message) it boots fine ft232h log with raminit debug enabled https://pastebin.com/e8xhet1V Any ideas? Thx If I need more debugging options please tell me how to enable it, thx -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #335] (Closed) High prority bug causes bricking when tianocore and flash log console used together
Issue #335 has been updated by Martin Roth. Status changed from New to Closed No response to comments asking for clarification in over a year. Closing. Bug #335: High prority bug causes bricking when tianocore and flash log console used together https://ticket.coreboot.org/issues/335#change-1371 * Author: xinhua wang * Status: Closed * Priority: Normal * Start date: 2022-01-04 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 @ 69 (262144 bytes) smm store: 4 # blocks with size 0x1 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 ) 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #392] (Response Needed) coreboot 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error"
Issue #392 has been updated by Martin Roth. Status changed from New to Response Needed Is this fixed now? There was a revert of the patch that caused the problem, but that was abandoned with a comment saying that another pair of patches fixed the issue. Unfortunately, one of those two patches was also abandoned with no reason given. Revert: https://review.coreboot.org/c/coreboot/+/65501 (Abandoned) Fix patch 1: https://review.coreboot.org/c/coreboot/+/66255 (Abandoned) Fix patch 2: https://review.coreboot.org/c/coreboot/+/66256 (Merged) Can anyone verify whether this is still an issue or some other patch fixed it? Bug #392: coreboot 4.17 - SeaBIOS Windows 10 BSOD "ACPI Error" https://ticket.coreboot.org/issues/392#change-1366 * Author: Pawel Radomychelski * Status: Response Needed * Priority: Normal * Category: board support * Target version: 4.17 * Start date: 2022-06-18 * Affected versions: 4.17, master * Related links: https://ticket.coreboot.org/issues/327 * Affected hardware: Lenovo ThinkPad X230 Tablet * Affected OS: Windows 10 Since CoreBoot 4.16 my Windows 10 cant boot from SeaBios, i get BSOD with "ACPI Error" very early. Don't know which commit exactly brakes ACPI, but i can say, that in my CoreBoot 4.15 Image from 11/09/2021 Windows 10 is booting just fine from SeaBIOS. Some time later under CoreBoot 4.16 i saw that windows is BSODing. Tried yesterday with CoreBoot 4.17 and its still broken. I think, since CB4.16 there is something broken in ACPI. As i read, the problem is, that ACPI reserves some memory area, which in Windows is reserved for the system. This [[https://ticket.coreboot.org/issues/327]] seems to be a similar problem, but the guy is using TianoCore instead of SeaBIOS. Changing the line OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) to OperationRegion (OPRG, SystemMemory, ASLS, 0x1000) doesnt fix it for SeaBios, but fix it for TianoCore. ---Files dmesg_cb415.txt (78.9 KB) dmesg_cb417.txt (79.9 KB) .config (19.7 KB) CB4.17_BSOD.jpg (143 KB) CB415.log (46.4 KB) CB417.log (128 KB) CB416.log (128 KB) dmesg_cb416.txt (81.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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #436] (Resolved) Berknip doesn't want to boot with the built image
Issue #436 has been updated by Martin Roth. Status changed from New to Resolved This is actually a much bigger question than just berknip. Many of the coreboot "default" configs are not bootable, either due to requiring binaries that are not redistributable. I've added that question to the next coreboot leadership meeting. Since the berknip board is working and the problem was a config issue, I'm marking this as resolved. Bug #436: Berknip doesn't want to boot with the built image https://ticket.coreboot.org/issues/436#change-1364 * Author: Balazs Vinarz * Status: Resolved * Priority: Normal * Target version: none * Start date: 2022-11-01 * Affected hardware: Google Berknip (Zork) * Affected OS: NA I was trying to flash the build 4.18 Coreboot image for my HP c645, as only RW_LEGACY image was available for this machine at MrChromebox. Now the machine, heat's the CPU if I plug in the USB-C adapter or the battery, but shows no image at all. I can manage to flash back the original image, I just wanted to highlight this. Build logs are added as attachments. I compared the CBFS regions side by side and it seems: * Google build only 1 microcode blob, while I have 3 and * the VBGFX.bin is missing at my build, however however the optionroms for the iGP is added. ``` diff apu/amdfw 0x5aafc0 raw 13155 | apu/amdfw 0x5aafc0 amdfw 12574 bootblock 0x77afc0 bootblock 655 | build_info 0x27e00raw cbfs master header 0x0cbfs header | cbfs_master_header 0x0cbfs header config 0x2b840raw 8 | config 0x27940raw 4 cpu_microcode_blob.bin 0xd5c0 microcode96 | cpu_microcode_8180.bin 0x7a80 microcode32 (empty)0x48280null 33 | cpu_microcode_8181.bin 0x8740 microcode32 (empty)0x52d3c0 null 5150 | cpu_microcode_8201.bin 0x9400 microcode32 (empty)0x6ec300 null 5848 | (empty) 0x6de000 null 7085 fallback/dsdt.aml 0x2bf00raw 157 | (empty) 0x81c00null 54117 fallback/payload 0x511a00 simple elf 1129 | fallback/dsdt.aml 0x27ec0raw 155 fallback/ramstage 0xfbc0 (unknown) 1136 | fallback/payload 0x6fac0simple elf 718 fallback/romstage 0x80 (unknown) 545 | fallback/ramstage 0xa0c0 stage 1208 > fallback/romstage 0x80 stage 310 FMAP REGION: COREBOOT FMAP REGION: COREBOOT font.bin 0x4e4a80 raw 50 | fspm.bin 0x2bc00fsp 996 fspm.bin 0x2fcc0fsp 994 | fsps.bin 0x44180fsp 697 fsps.bin 0x48fc0fsp 692 | header_pointer 0x78afc0 cbfs header locale_ar.bin 0x46dcc0 raw 789 < locale_bg.bin 0x157d40 raw1109 < locale_bn.bin 0x1185c0 raw 981 < locale_ca.bin 0x1d9e40 raw 969 < locale_cs.bin 0x42c980 raw 954 < locale_da.bin 0x1f1980 raw 938 < locale_de.bin 0x9e1c0raw1121 < locale_el.bin 0xf95c0raw1269 < locale_en.bin 0x4fd040 raw 843 < locale_es-419.bin 0x2b1200 raw1058 < locale_es.bin 0x4145c0 raw 991 < locale_et.bin 0x269400 raw 858 < locale_fa.bin 0x4b0900 raw 787 < locale_fi.bin 0x2cb000 raw 902 < locale_fil.bin 0x1a8500 raw1005 < locale_fr.bin 0x24ee40 raw1078 < locale_gu.bin 0x3e8f40 raw 824 < locale_he.bin 0xd1340raw 559 < locale_hi.bin 0x221780 raw 796 < locale_hr.bin 0x38a380 raw 970 < locale_hu.bin 0xdee00raw1084 < locale_id.bin 0x3a1f00 raw 924 <
[coreboot] [coreboot - Bug #440] (Response Needed) superiotool tells you to run it as root and stops even when ran as root
Issue #440 has been updated by Martin Roth. Status changed from New to Response Needed I'm not able to reproduce it on a genuine linux system. I don't think it's surprising that it wouldn't work on WSL as windows probably doesn't let the WSL linux kernel get close to real hardware. Can anyone else reproduce this issue? Bug #440: superiotool tells you to run it as root and stops even when ran as root https://ticket.coreboot.org/issues/440#change-1363 * Author: J Nky * Status: Response Needed * Priority: Normal * Target version: none * Start date: 2022-11-24 * Affected versions: 4.15 * Affected OS: ubuntu 22.10 On ubuntu 22.10: **sudo superiotool** iopl: Function not implemented Superiotool must be run as root. superiotool tells you to run it as root and stops even when ran as root -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #445] Thinkpad X200 wifi issue
Issue #445 has been updated by Martin Roth. It's entirely possible that coreboot is violating some of the power-on timings of that wifi module. This could cause it to work some of the time, but fail at other times. To fix this, or determine if this actually is a problem, someone would have to grab the datasheet for the the chip on that module and see what the timings are supposed to be. There are probably GPIOs to control the various power and enable signals to the chip. We'd have to see when those are actually being set to tell if the spec is being violated. This is entirely a guess on my part based on the work I've done on chromebooks getting the power-on timings for the PCIe slots to meet the specs for all of the modules we were using on a build. It's also possible as you mentioned that there's just something wrong with your individual module that's causing it to be flaky. Bug #445: Thinkpad X200 wifi issue https://ticket.coreboot.org/issues/445#change-1362 * Author: Masc Masc * Status: New * Priority: Normal * Target version: none * Start date: 2023-01-06 * Affected versions: 4.18 Compiled coreboot latest revision from source and built a coreboot rom image for X200 with SeaBIOS (also tried with Grub as a payload). The laptop beeps and the power LED flashes at startup and the wifi card does not work (cannot enable wifi in OS). The operating system is Debian Bullseye and the wifi card is an Atheros AR5B95. The OS boots normally, but no wifi is available. The wifi card has been tested and works fine with latest stable libreboot release. ---Files config (18.1 KB) cbmem.txt (42.4 KB) dmesg.txt (62.8 KB) lspci_nn_libreboot.txt (2.42 KB) lspci_tv_libreboot.txt (1.47 KB) lspci_vvvxx_libreboot.txt (31.1 KB) lspci_nn_coreboot.txt (2.42 KB) lspci_tv_coreboot.txt (1.48 KB) lspci_vvvxx_coreboot.txt (31.6 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Other #447] (Closed) X9SAE-V No Post - Need help recovering board.
Issue #447 has been updated by Martin Roth. Status changed from New to Closed Subject changed from X9SAE-V No Post to X9SAE-V No Post - Need help recovering board. Tracker changed from Bug to Other Hey, sorry about your board. Unfortunately, bad flashes and bad images happen. We always recommend making sure you have a way to recover your board before updating with coreboot. I'm You can also try flashing the ROM chip using the pomona clip with the board powered on, but with the reset button pressed. Obviously this can cause issues shorting the board out if something slips, so please only do this if you feel comfortable doing so. Beyond that, I'd recommend asking on the #flashrom channel on IRC. I'm closing this issue as there's no actual bug that we can respond to here. If you're able to recover your board and figure out where the problem that prevented it from booting is, please feel free to open a new bug addressing that issue. Best of luck! Other #447: X9SAE-V No Post - Need help recovering board. https://ticket.coreboot.org/issues/447#change-1361 * Author: Aaron Burton * Status: Closed * Priority: Normal * Target version: 4.19 * Start date: 2023-01-09 This one is a different story but may be related to my Optiplex 9010 issues. I recently updated coreboot on my X9SAE-V, using the same settings I had previously and after rebooting it doesn't seem to post. Previous build used SeaBIOS 1.15 (worked great), recent compile with SeaBIOS 1.16.1 and coreboot 4.19 causes no post. Did some research on the microchip used for flashing on this board but can't get it to flash externally using a Pomona 5250 w/ Raspberry pi. Guessing the pi either doesn't supply enough amperage on 3.3V for external flashing or the chip is in circuit with something on the board that requires the chip to be desoldered before reflashing externally. I have a copy of the stock bios and a working coreboot build, any suggestions for unbricking would be greatly appreciated before I try to source another board. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #386] (Closed) ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop
Issue #386 has been updated by Martin Roth. Status changed from New to Closed No update since Kyösti pointed out the issue in the boot log to indicate that this is anything beyond incompatible dimms. Closing. Bug #386: ASUS P8Z77-V LX2 - Raminit issue at second boot with two 8GiB DIMMs - bootloop https://ticket.coreboot.org/issues/386#change-1360 * Author: gzz5f gzz5f * Status: Closed * Priority: High * Category: board support * Target version: master * Start date: 2022-06-05 * Affected versions: master * Needs backport to: none * Affected hardware: ASUS P8Z77-V LX2 * Affected OS: all I build coreboot today for the ASUS P8Z77-V LX2 and used the latest coreboot master code. The 2 8GiB DIMMs are working fine at first boot. You can start computer, install from a live media the OS and so on. But at the second boot it failes boot forever and its bootooping. It does not make a change if i boot for a second until SeaBIOS output and then turn off the computer or use the computer for longer time. The second boot is always broken. Workaround 1: Remove one of the two 8GiB DIMMs. Then the computer also starts fine after a reboot. Workaround 2: Install two 4GiB DIMMs instead of two 8GiB DIMMs. Then the computer also starts fine after reboot. Workaround 3: At every boot boot for a second with one DIMM. Turn off the computer, insert the second DIMM and start it again. kmalkki told me to rebuid the image with DEBUG_RAM_SETUP=y I then build a second image, with DEBUG_RAM_SETUP=y. The logfile contains the first successfull boot (created with Workaround 3), the poweroff and the poweron with the bootloop. I have let it bootloop few times before turned off the PSU. ---Files coreboot_logfie.txt (197 KB) coreboot_logfile_cleaned.txt (160 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #343] (Resolved) Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:00009016 - Halting
Issue #343 has been updated by Martin Roth. Status changed from New to Resolved The patch https://review.coreboot.org/c/coreboot/+/64235 which was said to fix the issue was merged on 2022-11-02. Please reopen if the issue is still seen. Bug #343: Fails to load GRUB payload: CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:9016 - Halting https://ticket.coreboot.org/issues/343#change-1359 * Author: Paul Menzel * Status: Resolved * Priority: Normal * Start date: 2022-03-30 coreboot emulation/qemu-i440fx is unable to load GRUB payload. It works with SeaBIOS. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0cbfs header32 none fallback/romstage 0x80 stage 21944 none fallback/ramstage 0x56c0 stage 62048 LZMA (139536 decompressed) config 0x14980raw 428 none revision 0x14b80raw 716 none build_info 0x14e80raw 112 none fallback/dsdt.aml 0x14f40raw 4044 none cmos_layout.bin0x15f40cmos_layout 640 none fallback/postcar 0x16200stage 23328 none fallback/payload 0x1bd80simple elf 460906 none (empty)0x8c640null 3603556 none bootblock 0x3fc2c0 bootblock 15104 none ``` ``` […] [NOTE ] coreboot-4.16-415-ga84c00c9ce Wed Mar 30 01:18:14 UTC 2022 ramstage starting (log level: 7)... […] [INFO ] Timestamp - selfboot jump: 965162845 [EMERG] CPU Index 0 - APIC 0 Unexpected Exception:6 @ 10:9016 - Halting [EMERG] Code: 0 eflags: 00010002 cr2: [EMERG] eax: ebx: 3ffbdc18 ecx: 0001ac27 edx: 00ff [EMERG] edi: 3ffbdc00 esi: 3ffbdbf0 ebp: 01e4 esp: 3ffc3fbc [EMERG] 0x8fd0:00 00 00 00 00 00 00 00 [EMERG] 0x8fd8:00 00 00 00 00 00 00 00 [EMERG] 0x8fe0:00 00 00 00 00 00 00 00 [EMERG] 0x8fe8:00 00 00 00 00 00 00 00 [EMERG] 0x8ff0:00 00 00 00 00 00 00 00 [EMERG] 0x8ff8:00 00 00 00 00 00 00 00 [EMERG] 0x9000:52 52 68 27 ac 01 00 6a [EMERG] 0x9008:0b e8 5e cd 00 00 83 c4 [EMERG] 0x9010:10 a0 00 00 00 00 0f 0b [EMERG] 0x9018:51 51 68 6a a2 01 00 6a [EMERG] 0x9020:0b e8 46 cd 00 00 83 c4 [EMERG] 0x9028:10 eb e6 90 bc f0 ff 07 [EMERG] 0x9030:00 e9 c7 d7 00 00 66 90 [EMERG] 0x9038:02 b0 ad 1b 02 00 00 00 [EMERG] 0x9040:fc 4f 52 e4 55 57 56 53 [EMERG] 0x9048:83 ec 1c 8b 5c 24 30 8b [EMERG] 0x3ffc4038:0x0002 [EMERG] 0x3ffc4034:0x0003 [EMERG] 0x3ffc4030:0x [EMERG] 0x3ffc402c:0x [EMERG] 0x3ffc4028:0x [EMERG] 0x3ffc4024:0x [EMERG] 0x3ffc4020:0x [EMERG] 0x3ffc401c:0x [EMERG] 0x3ffc4018:0x [EMERG] 0x3ffc4014:0x [EMERG] 0x3ffc4010:0x [EMERG] 0x3ffc400c:0x [EMERG] 0x3ffc4008:0x [EMERG] 0x3ffc4004:0x [EMERG] 0x3ffc4000:0x [EMERG] 0x3ffc3ffc:0x [EMERG] 0x3ffc3ff8:0x3ffbd4e8 [EMERG] 0x3ffc3ff4:0xdeadbeef [EMERG] 0x3ffc3ff0:0xdeadbeef [EMERG] 0x3ffc3fec:0x3ff9e061 [EMERG] 0x3ffc3fe8:0x3ffa1f19 [EMERG] 0x3ffc3fe4:0x00018f20 [EMERG] 0x3ffc3fe0:0x3ffdcfd4 [EMERG] 0x3ffc3fdc:0x3ffc4000 [EMERG] 0x3ffc3fd8:0x3ffd63ac [EMERG] 0x3ffc3fd4:0x [EMERG] 0x3ffc3fd0:0x3ffa1fe5 [EMERG] 0x3ffc3fcc:0x3ffa2139 [EMERG] 0x3ffc3fc8:0x3ffbdc24 [EMERG] 0x3ffc3fc4:0x3ffa4303 [EMERG] 0x3ffc3fc0:0x3ff95000 [EMERG] 0x3ffc3fbc:0x3ffac8e4 <-esp ``` ---Files coreboot.log (17.2 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #443] (Resolved) acpica distfile changed
Issue #443 has been updated by Martin Roth.
Status changed from New to Resolved
Fixed in the latest toolchain.
Bug #443: acpica distfile changed
https://ticket.coreboot.org/issues/443#change-1358
* Author: Fabian Groffen
* Status: Resolved
* Priority: Normal
* Target version: none
* Start date: 2022-12-04
commit 58c79bc2537e408db2a8b5ce7723ed6dd0145652 (HEAD -> acpica-distfile-fix)
Author: Fabian Groffen
Date: Sun Dec 4 21:13:28 2022 +0100
crossgcc: fix distfile for acpica
For some reason this distfile was changed into something odd. But
update it.
Signed-off-by: Fabian Groffen
diff --git a/util/crossgcc/buildgcc b/util/crossgcc/buildgcc
index 0d349f2dfe..d9f7b73766 100755
--- a/util/crossgcc/buildgcc
+++ b/util/crossgcc/buildgcc
@@ -52,7 +52,7 @@
MPFR_ARCHIVE="https://ftpmirror.gnu.org/mpfr/mpfr-${MPFR_VERSION}.tar.xz;
MPC_ARCHIVE="https://ftpmirror.gnu.org/mpc/mpc-${MPC_VERSION}.tar.gz;
GCC_ARCHIVE="https://ftpmirror.gnu.org/gcc/gcc-${GCC_VERSION}/gcc-${GCC_VERSION}.tar.xz;
BINUTILS_ARCHIVE="https://ftpmirror.gnu.org/binutils/binutils-${BINUTILS_VERSION}.tar.xz;
-IASL_ARCHIVE="https://acpica.org/sites/acpica/files/acpica-unix2-${IASL_VERSION}.tar.gz;
+IASL_ARCHIVE="https://acpica.org/sites/acpica/files/acpica-unix2-${IASL_VERSION}.tar_0.gz;
# CLANG toolchain archive locations
LLVM_ARCHIVE="https://github.com/llvm/llvm-project/releases/download/llvmorg-${CLANG_VERSION}/llvm-${CLANG_VERSION}.src.tar.xz;
CLANG_ARCHIVE="https://github.com/llvm/llvm-project/releases/download/llvmorg-${CLANG_VERSION}/clang-${CLANG_VERSION}.src.tar.xz;
diff --git a/util/crossgcc/sum/acpica-unix2-20221020.tar.gz.cksum
b/util/crossgcc/sum/acpica-unix2-20221020.tar_0.gz.cksum
similarity index 100%
rename from util/crossgcc/sum/acpica-unix2-20221020.tar.gz.cksum
rename to util/crossgcc/sum/acpica-unix2-20221020.tar_0.gz.cksum
--
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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #441] (Closed) [resolved]
Issue #441 has been updated by Martin Roth. Status changed from New to Closed Closing as resolved. Bug #441: [resolved] https://ticket.coreboot.org/issues/441#change-1357 * Author: U dent * Status: Closed * Priority: Low * Start date: 2022-11-27 * Affected versions: none **short journalctl -b** > Nov 27 21:19:37 debian kernel: mei_me :00:16.0: H_RST is set = 0x8015 > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: wait hw ready failed > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: hw_start failed ret = -62 > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: reset: reached maximal > consecutive resets: disabling the device > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: reset failed ret = -19 > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: link layer initialization > failed. > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: init hw failure. > Nov 27 21:19:39 debian kernel: mei_me :00:16.0: initialization failed.` **short cbmem -1** > [CRIT ] intel_me_path: mbp is not ready! > [NOTE ] ME: BIOS path: Error > [ERROR] ME: MBP not ready **also notice** > Nov 27 21:26:57 debian kernel: usb usb1-port9: over-current condition > Nov 27 21:26:57 debian kernel: usb usb1-port10: over-current condition -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #432] (Closed) t440p reboots on suspend
Issue #432 has been updated by Martin Roth. Status changed from Response Needed to Closed Closing as not an issue in coreboot. Bug #432: t440p reboots on suspend https://ticket.coreboot.org/issues/432#change-1356 * Author: Josh R * Status: Closed * Priority: Normal * Target version: none * Start date: 2022-10-21 * Affected versions: 4.15 * Related links: https://ticket.coreboot.org/issues/412 * Affected hardware: Lenovo ThinkPad T440p * Affected OS: Ubuntu 22.04 (Pop OS) Per request, adding new ticket for an issue with my t440p where attempting to resume on suspend results in a reboot (or at least, not resuming from DRAM). My t440p already has coreboot installed (via osbmk). Following instructions from issue #412, I have attempted the following: `sudo flashrom -p internal --ifd -i bios -w the_full_12MiB_osbmk.rom --noverify-all` ...but that did not seem to do the trick (still "restarts" without resuming from RAM). Note that I am using the "full" 12MB osbmk rom (not split by 4MiB and 8MiB, as that seemed intended for the hardware flashing instructions). coreboot version looks like 4.15.204, and flashrom version 1.2-640. If it helps, attached cbmem -1 output with a "normal boot" followed by a later resume from suspend (that resulted in a restart). Thanks in advance. I guess you don't realize how much you use suspend until it doesn't work anymore :) ---Files cbmem.20221019195923.normal_boot.log (36.2 KB) cbmem.20221019200724.from_suspend.log (36.3 KB) osboot_t440p_ifd_bin_is_also_borked.log (10.2 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #19] Violations of Coding guidelines: All objects should have fully qualified types (unsigned int instead of unsigned)
Issue #19 has been updated by Martin Roth. Some utilities and payload code still uses bare unsigned, but this is completely fixed in the coreboot src/ directory. There are unfortunately some false positives within names and comments, so the lint test should be updated in addition to fixing the above issues. Bug #19: Violations of Coding guidelines: All objects should have fully qualified types (unsigned int instead of unsigned) https://ticket.coreboot.org/issues/19#change-1355 * Author: Martin Roth * Status: New * Priority: Normal * Start date: 2015-12-30 Some (most?) of these can be seen using the following command: grep -Grin 'unsigned' | grep -v 'unsigned[[:space:]]*int\|unsigned[[:space:]]*long\|unsigned[[:space:]]*char\|unsigned[[:space:]]*short' -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #36] (Closed) x201: stuck ec event
Issue #36 has been updated by Martin Roth. Status changed from New to Closed No updates in 7 years. Closing. Please reopen if this is still an issue. Bug #36: x201: stuck ec event https://ticket.coreboot.org/issues/36#change-1354 * Author: Alexander Couzens * Status: Closed * Priority: Normal * Start date: 2016-03-10 sometime the ec on x201 is stuck in a queue which results in all fn buttons and lid isn't working. so most of the acpi events aren't generated. ec 0x34 bit 3 - attention is disabled temporary might interesting. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #33] (Closed) cbmem utility fails on newer linux kernels "Failed to mmap /dev/mem: Resource temporarily unavailable"
Issue #33 has been updated by Martin Roth. Status changed from New to Closed Closing as fixed. Bug #33: cbmem utility fails on newer linux kernels "Failed to mmap /dev/mem: Resource temporarily unavailable" https://ticket.coreboot.org/issues/33#change-1353 * Author: Martin Roth * Status: Closed * Priority: Normal * Start date: 2016-02-05 This has been going on for a while. Paul mentioned it here: https://www.coreboot.org/pipermail/coreboot/2015-September/080383.html -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #27] (Closed) Windows doesn't like references in ACPI to objects that are only defined later
Issue #27 has been updated by Martin Roth. Status changed from New to Closed Marking as closed due to the last update being 7 years old. Please reopen if we have a new update. Bug #27: Windows doesn't like references in ACPI to objects that are only defined later https://ticket.coreboot.org/issues/27#change-1352 * Author: Patrick Georgi * Status: Closed * Priority: Normal * Start date: 2016-01-29 There is some concern about Windows not liking ASL structured like in https://review.coreboot.org/#/c/13506/ because NVSA is defined "after" the OpRegion that uses it. Needs testing and potentially a tree-wide solution -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #20] Add make target to check if toolchain is up to date
Issue #20 has been updated by Martin Roth. Affected versions 4.18 added This was completed, but seems like it may now be broken again. The command 'make test-toolchain' should tell you if the toolchain version you are using is current, but currently reports that the toolchain is up-to-date even when that's not the case. Feature #20: Add make target to check if toolchain is up to date https://ticket.coreboot.org/issues/20#change-1351 * Author: Timothy Pearson * Status: In Progress * Priority: Normal * Assignee: Martin Roth * Category: build system * Start date: 2015-12-30 * Affected versions: 4.18 Various automated build/test services use a specific toolchain build for all tests, and have no way to know if the toolchain has been updated and requires a rebuild. This, in turn, means manual intervention is needed for these services every time the toolchain version changes. (unless various hacks involving searching the output text are used, but these are highly suboptimal). A new make target to check if the built toolchain is completely up to date with the current coreboot versions would be very useful. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #12] (Closed) Use of CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is a mess
Issue #12 has been updated by Martin Roth. Status changed from New to Closed Closing as fixed. Bug #12: Use of CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is a mess https://ticket.coreboot.org/issues/12#change-1349 * Author: Martin Roth * Status: Closed * Priority: Normal * Start date: 2015-11-27 In Kconfig, the symbol MAINBOARD_POWER_ON_AFTER_POWER_FAIL is used in a few platforms. It is a bool. Because it's used in only a few mainboards, for MOST platforms, it's going to be defined as 0 (kconfig bools in coreboot are ALWAYS defined) Here are those mainboards: > src/mainboard/samsung/lumpy/Kconfig > src/mainboard/samsung/stumpy/Kconfig > src/mainboard/asus/kgpe-d16/Kconfig > src/mainboard/asus/kfsn4-dre/Kconfig > src/mainboard/asus/kfsn4-dre_k8/Kconfig > src/mainboard/msi/ms9652_fam10/Kconfig In a number of other platforms, CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL is used as if it were a standard #define - with three states: from src/southbridge/intel/bd82x6x/pch.h: #define MAINBOARD_POWER_OFF 0 #define MAINBOARD_POWER_ON 1 #define MAINBOARD_POWER_KEEP2 #ifndef CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL #define CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL MAINBOARD_POWER_ON #endif Similar patterns are seen in these files: > src/southbridge/amd/agesa/hudson/sm.c > src/southbridge/amd/amd8111/acpi.c > src/southbridge/amd/pi/hudson/sm.c > src/southbridge/amd/sb600/sm.c > src/southbridge/amd/sb700/sm.c > src/southbridge/amd/sb800/sm.c > src/southbridge/intel/bd82x6x/pch.h > src/southbridge/intel/fsp_bd82x6x/pch.h > src/southbridge/intel/fsp_i89xx/pch.h > src/southbridge/intel/fsp_rangeley/soc.h > src/southbridge/intel/i3100/lpc.c > src/southbridge/intel/i82801dx/i82801dx.h > src/southbridge/intel/i82801ex/lpc.c > src/southbridge/intel/i82801gx/i82801gx.h > src/southbridge/intel/i82801ix/i82801ix.h > src/southbridge/intel/ibexpeak/pch.h > src/southbridge/intel/lynxpoint/pch.h > src/southbridge/nvidia/ck804/lpc.c > src/southbridge/nvidia/mcp55/lpc.c > src/southbridge/sis/sis966/lpc.c > src/southbridge/via/vt8237r/vt8237r.h > src/superio/nuvoton/nct5572d/superio.c To fix: * Make sure definitions are the same across all the platforms and fix them to be consistent if they're not already: ** 0 = power off, 1 = power on, 2 = restore previous state * Add Kconfig symbols to show which platforms get these options based on which platforms are using the option - Everything using CONFIG_MAINBOARD_POWER_ON_AFTER_POWER_FAIL needs to be set. ** HAVE_POWER_STATE_ON_AFTER_FAIL - This gets set for platforms that get the option ** HAVE_POWER_STATE_RESTORE - This gets set for platforms that can actually restore the previous state * Turn the MAINBOARD_POWER_ON_AFTER_POWER_FAIL bool into a choice menu and move it to a higher level in the Kconfig tree. * Add the HAVE_POWER_STATE_ON_AFTER_FAIL and HAVE_POWER_STATE_RESTORE to the correct Kconfigs * Remove all of the existing #define stuff from the above files. * Remove the current MAINBOARD_POWER_ON_AFTER_POWER_FAIL Kconfig options from their current locations (with the exception of setting new defaults) * Test. -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #14] (Closed) printout lenovo ec power cause register
Issue #14 has been updated by Martin Roth. Status changed from New to Closed Closing due to No updates in 7 years. Please reopen if needed. Feature #14: printout lenovo ec power cause register https://ticket.coreboot.org/issues/14#change-1348 * Author: Alexander Couzens * Status: Closed * Priority: Normal * Assignee: Alexander Couzens * Category: board support * Start date: 2015-11-28 -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #7] (Closed) gnawty support based on acer cb3-111
Issue #7 has been updated by Martin Roth. Status changed from In Progress to Closed No updates in 7 years. Closing. Feature #7: gnawty support based on acer cb3-111 https://ticket.coreboot.org/issues/7#change-1347 * Author: Alexander Couzens * Status: Closed * Priority: Normal * Assignee: Alexander Couzens * Category: board support * Start date: 2015-11-20 Adding google gnawty boards. This board is very similiar to rambi, the only difference known is the ram configuration. http://review.coreboot.org/#/c/12500 https://www.coreboot.org/Board:acer/cb3-111 SeaBIOS hangs with message: Press F12 ... but pressing f12 does nothing. ~~Booting ELF payload with openwrt fails because e820 isn't properly passed.~~ Using Linux Payload + x64 kernel openwrt boots up. ---Files bootup_x86_64_openwrt (60 KB) vga_bios_hangs (29.1 KB) dmesg (63.6 KB) lspci_vvv (10.3 KB) lspci (789 Bytes) lspci_vvttnn (716 Bytes) booting_4.1 (58.7 KB) booting_4.1_with_ioapic (63.5 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Feature #4] (Closed) Documentation for coreboot's public interface
Issue #4 has been updated by Martin Roth. Status changed from New to Closed We've done a significant amount of work on coreboot's documentation over the past 7 years. Closing this as completed. If there is any additional documentation needed, please file a new bug stating exactly what needs to be documented. Feature #4: Documentation for coreboot's public interface https://ticket.coreboot.org/issues/4#change-1346 * Author: Patrick Georgi * Status: Closed * Priority: Normal * Start date: 2015-11-18 We need some structured documentation on what can be expected to be the stable coreboot interface. This (probably) covers * cbfs (and in the future, fmap) format * cbtables (and its various table formats, incl. cbmem entries) * The calling convention into the payload (per arch) * references to ACPI, DMI, PIR, etc -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Support #387] (Closed) Support Framework Laptop
Issue #387 has been updated by Martin Roth. Status changed from New to Closed Closing this issue. The framework chromebook will be supported in tree as typical for chromebooks. If other versions of the framework laptops are to be supported, someone can add them to the tree, and we welcome those submissions. Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387#change-1345 * Author: Jun Aruga * Status: Closed * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the > coreboot community. Our plan in the near term is to help them create a shim > loader that can be signed to run on any Framework Laptop, which then enables > anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 ---Files Emails_with_Framework_customer_support_about_coreboot.pdf (283 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Thoughts on changing indentation for devicetree.cb files
I wanted to see what people think about changing the indentation for devicetree.cb files (including overridetree.cb and chipset.cb files) We currently use tabs to indent, which my editor has set to 8 spaces across all of coreboot, but these aren't C files, and maybe shouldn't be treated the same. We have deep indentations for the devicetree files, making the lines very long and causing them to wrap significantly when reviewing them in gerrit. I know I'm suggesting heresy here, but what do people think about changing the devicetree files to use indentation with spaces, at either 2 or 4 characters per level? I acknowledge that this could just be a me problem, but thought I'd bring it up. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Toolchain build on Ubuntu 22.04 fails (at GCC 8.3.0)?
If it would help, we could supply a VM with each release that had the coreboot toolchain pre-built. It's also possible to use the released docker images to rebuild coreboot - those already contain the toolchain. The advantages to both of these is that you'd be building in the environment that was originally used at the time the code was developed - that works around a significant number of problems that you could be running int. If you're interested in either of those options, let me know and I'll supply images and instructions to get you up and running. Martin Jan 8, 2023, 12:16 by rminn...@gmail.com: > But in some cases static libs are no longer provided at all. Would be nice to > know if that's the case for libuuid. > > On Sun, Jan 8, 2023, 9:24 AM Nico Huber <> nic...@gmx.de> > wrote: > >> On 08.01.23 17:42, ron minnich wrote: >> > For reasons I still don't understand, the various linux distros no longer >> > ship .a as part of the library package. >> >> They ship them separately. On Ubuntu, usually a -dev package. I even >> recall -devel-static packages (-devel was headers only and such) >> ~20 years back. >> >> The reason to ship them separately is simple: not everybody has the >> space/bandwidth to spare. These habits are decades old. Some newer >> distros moved to ship everything in one package, though. >> >> One odd thing about libuuid: The Ubuntu package is called uuid-dev >> (not libuuid-dev). That's something I don't understand ;) >> >> Nico >> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Status of maintained boards and policies?
Hey Denis, My reply got out of control here. Apologies for the length, feel
free to ignore the top and just skip to my replies. :)
The points you bring up are definitely valid, but coreboot isn't Linux. We
don't have the same infrastructure, or investment from companies. coreboot has
no "full time" contributors as such. We have a number of contributors from
various companies who need to get their products shipped, but they all have
varying amounts of time to spend on the project. It's a tiny tiny fraction of
what Linux gets.
I don't mean to say that coreboot is a small project - we're not. In the past
year, we've gotten contributions from over 350 different people. Most of these
contributions are from people who work on coreboot as a job. Those aren't the
people who keep the project alive though. There are really just a couple of
dozen people at any given time who actually do the work on the coreboot project
outside of the individual patches they're assigned to do for their jobs.
Unfortunately, that's simply not enough people to maintain all of the platforms
and chips in the tree the way things are currently. We could do something like
add a requirement that each platform added needs to donate two (or choose an
arbitrary number) boards to the coreboot project that we install somewhere and
test on a (daily/weekly/monthly) basis to make sure that they're working.
Currently we don't have the funds or a place to do that. It also puts a burden
on an individual who wants to add a board to the coreboot tree. It creates
problems for companies that use coreboot for an embedded system that isn't easy
to test.
Looking forward:
coreboot just got our first "large" donation from Google to support the build
servers for the next year. Until now, the build servers have mainly been
running from my house. We've reached the point where the project can no longer
run as a hobby-project on a hobby-project budget.
If we're going to actually be more than a hobby-project going forward, I think
we're going to need to expand our scope and make changes to the way we do
things. This is going to require making changes to better define how things
like code deprecation is handled.
I think you're right that we need some way to guarantee that boards added to
coreboot aren't going to be dropped again in a short period of time, but that
requires investment from companies using coreboot to make sure that it happens.
When a chip is added to coreboot, how long is a company expected to maintain
that chip in the coreboot repository? If we make it too short, nobody wants to
develop mainboards for it. If we make that time too long, chip vendors aren't
going to want to add their chips to the tree. I'm not sure how to balance that.
Jan 3, 2023, 17:17 by gnu...@cyberdimension.org:
> On Tue, 3 Jan 2023 18:38:02 +0100 (CET)
> Martin Roth wrote:
>
>> Hi Denis,
>> - Responses inline
>>
> Hi,
>
> Thanks for the answers.
>
>> Jan 2, 2023, 17:16 by gnu...@cyberdimension.org:
>>
>> > Hi,
>> >
>> > The MAINTAINERS file has the following:
>> >
>> >> PC ENGINES ALL MAINBOARDS
>> >> M: Piotr Król
>> >> M: Michał Żygowski
>> >> S: Supported
>> >> F: src/mainboard/pcengines/
>> >>
>> >
>> > But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*:
>> > Remove AMD family14 boards") actually removed the apu1
>> > (src/mainboard/pcengines/).
>> >
>> > Is there some policy somewhere that describes what kind of support
>> > to expect from maintained boards?
>> Yes, It's in the maintainers file itself:
>>
>> Supported: Someone is continuously paid to look after
>> this and a reaction to review requests can be expected
>> within a few days, a month at most.
>>
> [...]
>
>> Because the maintainers may not notice the patches, it's always
>> suggested to reach out to the maintainers directly for reviews.
>>
> As I understand that file tells only about patch review delays and not
> what kind of patches are acceptable or not or who is supposed to do the
> work of converting a board to the newer APIs. I'm mostly interested in
> two last aspects.
>
> For instance as a Linux contributor, I can send a patch to add a
> computer (like a smartphone for instance) or contribute fixes and new
> support to existing drivers, and usually the code gets maintained
> somehow automatically:
> - New patches are required not to break existing code, so they have to
> take care to either keep the compatibility with the old code or
> update it along the way.
>
> Though older code doesn't necessarily benefit from n
[coreboot] Re: Status of maintained boards and policies?
Hi Denis,
- Responses inline
Jan 2, 2023, 17:16 by gnu...@cyberdimension.org:
> Hi,
>
> The MAINTAINERS file has the following:
>
>> PC ENGINES ALL MAINBOARDS
>> M: Piotr Król
>> M: Michał Żygowski
>> S: Supported
>> F: src/mainboard/pcengines/
>>
>
> But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*: Remove
> AMD family14 boards") actually removed the apu1
> (src/mainboard/pcengines/).
>
> Is there some policy somewhere that describes what kind of support to
> expect from maintained boards?
>
Yes, It's in the maintainers file itself:
Supported: Someone is continuously paid to look after this and
a reaction to review requests can be expected
within a few days, a month at most.
Maintained: Someone actually looks after it and a reaction to
review requests can usually be expected within a
few weeks.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you
should be using that.
Because the maintainers may not notice the patches, it's always suggested to
reach out to the maintainers directly for reviews.
> Is there also a policy that explains when boards are removed? Or what
> to do to prevent boards from being removed?
>
We do have that policy, though it could probably be written a bit more plainly.
Here's the search in the coreboot documentation.
https://doc.coreboot.org/search.html?q=deprecation_keywords=yes=default
Here's the template for the release notes:
Deprecation notices are part of release notes to act as a warning: at somepoint
in the future some part of coreboot gets removed. That point must beat least 6
months after the release of the notice and it must be right aftersome release:
That is, the specified release must still contain the part inquestion while one
git commit later it might be removed.
The usual reason is progress: Infrastructure module X has been replaced
byinfrastructure module X+1. Removing X helps keep the sources manageableand
likely opens opportunities to improve the codebase even more.Sometimes
everything using some module has been converted to its successoralready and
it’s natural for such modules to be removed. Even then it mightbe useful to add
an entry to the release notes to make everybody aware ofsuch a change, for
maintainers of incomplete boards that they might keep intheir local trees and
also to give credit to the developers of that change.
> For instance u-boot warns when building that a boards needs to be
> adjusted to the newer driver model. So just by building u-boot you know
> in advance what needs to be fixed and for when.
>
> I've looked in the Coreboot documentation but I didn't find any
> information about that.
>
Someone could definitely add something to put up a notice when doing the build,
but that doesn't exist right now. If it's not something that you're interested
in doing, you could file a bug if you think it should be added.
> Also is there some public information on how much work it is to avoid a
> board being removed? Does it require to dedicate someone full time on
> it? Or does it usually requires less time?
>
It depends on the item. I don't know what "usually" might be in this case.
> Also how changes that break other people's code are decided? Can anyone
> submit these changes and get them accepted with very few people
> agreeing to them? Or is there another procedure for these special
> changes?
>
People are not allowed to knowingly submit changes that break other platforms.
If they do submit a change that breaks things, it can either be reverted, or
people can work together to fix the issue. This of course depends on the issue
and its severity.
I hope this helps answer your questions.
Martin
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #431] (New) fix src/arch/x86/smbios issues
Issue #431 has been reported by Martin Roth. Bug #431: fix src/arch/x86/smbios issues https://ticket.coreboot.org/issues/431 * Author: Martin Roth * Status: New * Priority: Normal * Assignee: Solomon Alan-Dei * Category: coreboot common code * Target version: none * Start date: 2022-10-20 There are currently 20 coverity issues affecting smbios code in src/arch/x86/smbios* https://scan6.scan.coverity.com/reports.htm#v55284/p10744 https://docs.google.com/spreadsheets/d/1hacitQU1zn7CU44eXP3xVdvq-OjnIF_h8LR8xZwh51c/preview ---Files Outstanding+Issues+in+smbios.csv (3.61 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #430] Fix util/cbfstool coverity issues
Issue #430 has been updated by Martin Roth. Assignee set to Solomon Alan-Dei Bug #430: Fix util/cbfstool coverity issues https://ticket.coreboot.org/issues/430#change-1202 * Author: Martin Roth * Status: New * Priority: Normal * Assignee: Solomon Alan-Dei * Category: userspace utilities * Target version: none * Start date: 2022-10-20 There are currently 25 coverity issues against files in the util/cbfstool directory: https://scan6.scan.coverity.com/reports.htm#v55283/p10744 https://docs.google.com/spreadsheets/d/1hacitQU1zn7CU44eXP3xVdvq-OjnIF_h8LR8xZwh51c/preview ---Files Outstanding+Issues+in+cbfstool.csv (4.47 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #430] (New) Fix util/cbfstool coverity issues
Issue #430 has been reported by Martin Roth. Bug #430: Fix util/cbfstool coverity issues https://ticket.coreboot.org/issues/430 * Author: Martin Roth * Status: New * Priority: Normal * Category: userspace utilities * Target version: none * Start date: 2022-10-20 There are currently 25 coverity issues against files in the util/cbfstool directory: https://scan6.scan.coverity.com/reports.htm#v55283/p10744 https://docs.google.com/spreadsheets/d/1hacitQU1zn7CU44eXP3xVdvq-OjnIF_h8LR8xZwh51c/preview ---Files Outstanding+Issues+in+cbfstool.csv (4.47 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Reconsidering the Gerrit submission strategy
Felix, If you've formed an opinion, maybe you want to take a break from submitting for a bit to let others test out the new submission strategy? For everyone else, I'd like to note that over the past year, Felix has hit submit on more than 45% of all of the coreboot patches that have been merged. The next highest submitter merged just over 10% and the person after that merged 5.5%. I'd weigh Felix's opinions on this matter very strongly. If we continue with this method (and for the rest of this month), I think we want to encourage shorter patch trains, consisting of only related patches. Currently, it seems like projects will occasionally build up enormous trains of patches that aren't necessarily related so that they can pull all of their patches at once just by grabbing the last one. It also sounds like rebasing all of the patches so that the entire train is contiguous is really needed - no more patches based on older versions of the previous patch. I think the same is true for abandoned patches - rebase everything so that the patch train isn't broken in the middle. Martin Aug 2, 2022, 14:02 by felix-coreb...@felixheld.de: > Hi Peter, > >> By "keep an overview" I mean to know which commits in a pushed branch >> that have been reviewed and which not. >> > > Ah, ok; I'd assume that Gerrit won't allow pushing a series of patches if one > patch in there doesn't have +2 and +1 verified yet. Haven't verified this > though. > >> I'm all for skipping unneeded build load [...] >> What am I missing here? >> > > Let's assume that we have a patch train with 10 patches and during the review > a typo fix in the first patch is requested and all other patches got +2s > without any change requests. Until now the solution was to update the first > patch and only push the first patch with the typo fix and just leave the > following 9 patches at their initial version, so Jenkins won't build those 9 > patches again. When re-pushing the full patch train, the other 9 patches will > get build tested again after the unnecessary update and again when the > patches get submitted. I don't think that this is a huge problem, but still > something to think about if we want to change this from what we've done in > the recent past. > >>> I reread the documentation and the thing I missed in there is that >>> Gerrit will only automatically rebase a patch when submitting when none >>> of the files it changed have been changed between the parent commit of >>> the to be submitted patch and the current top of tree. >>> >> >> That seems like an improvement to me. By the way, I don't think Gerrit >> has ever actually rebased anything, nor will it with the new setting, >> I understand it to always do an equivalent of "git cherry-pick" but >> with different requirements with the new strategy. >> > > Rebases have always been manual, but before it didn't matter too much, since > the cherry-pick strategy just tries to cherry-pick a commit and only requires > a manual rebase when there's a git conflict that makes the cherry-pick fail. > Now it requires a manual rebase when any of the files the commit changes have > been changed in the meantime and not only when there are git conflicts, which > happens way more often; especially when there are tree-wide changes or in the > case of patch trains where the patches change the same files; see my next > answer on the latter. > >> Hmm, how so? Submitting one commit at a time should make top of tree >> always match the parent commit of the to-be-submitted commit, right? >> > > That was my assumption, but that turned out to not be the case which was the > main reason for my first email today. Gerrit adds some lines to the commit > message which will change the git hash; maybe that's part of the reason? > > There was a patch train with at least the first few commits being submittable > and after i submitted the first patch, Gerrit now shows merge conflicts on > all following patches that should still be mergeable which is a dealbreaker > for me. If you want to have a look yourself: CB:66272 was the first patch i > submitted and now CB:66273 and following suddenly have merge conflicts which > they didn't have before. > > Regards, > Felix > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Intel sandybridge northbridge with ibexpeak southbridge?
Hello, I have a platform (Advantech NAMB-3250MB, used in some Riverbed appliances) which uses Sandy/Ivy Bridge CPUs, but has a DH89xxCC southbridge which according to ifdtool is Ibex Peak. [3] The ME firmware version from the vendor firmware is 6.0.50.1244 which also corresponds to Ibex Peak (Series 5) and not Cougar Point (Series 6). [1] I did not know it was possible to pair a Series 5 chipset with Sandy/Ivy Bridge, since the DH89xxCC only supports DMI 1 (intel-communications-chipset-89xx-series-datasheet.pdf page 5) and Sandy/Ivy Bridge support DMI 2.0 [2] It would appear that using northbridge/intel/sandybridge with southbridge/intel/ibexpeak in coreboot is not supported: /opt/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/romstage/northbridge/intel/sandybridge/early_dmi.o: in function `early_init_dmi': /opt/coreboot/src/northbridge/intel/sandybridge/early_dmi.c:175: undefined reference to `early_pch_init_native_dmi_pre' /opt/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: /opt/coreboot/src/northbridge/intel/sandybridge/early_dmi.c:215: undefined reference to `early_pch_init_native_dmi_post' /opt/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: build/romstage/northbridge/intel/sandybridge/raminit.o: in function `init_dram_ddr3': /opt/coreboot/src/northbridge/intel/sandybridge/raminit.c:322: undefined reference to `early_pch_init_native' src/arch/x86/Makefile.inc:185: recipe for target 'build/cbfs/fallback/romstage.debug' failed make: *** [build/cbfs/fallback/romstage.debug] Error 1 There is no early_pch_init_native_* in src/southbridge/intel/ibexpeak Is it safe to assume that IronLake northbridge is not applicable to Sandy/Ivy Bridge CPUs? In which case, I guess the only way this platform could ever be supported is if the missing early_pch_init_native_* functions are implemented for IbexPeak? Kind regards, Hal Martin [1] https://en.wikichip.org/wiki/intel/management_engine [2] https://www.intel.com/content/www/us/en/products/platforms/details/crystal-forest.html?s=Newest [3] ./ifdtool dump.bin PCH Revision: 5 series Ibex Peak FLMAP0:0x02040002 NR: 2 FRBA:0x40 NC: 1 FCBA:0x20 FLMAP1:0x10100206 ISL: 0x10 FPSBA: 0x100 NM: 2 FMBA:0x60 FLMAP2:0x0120 PSL: 0x0001 FMSBA: 0x200 FLUMAP1: 0x02ef Intel ME VSCC Table Length (VTL):2 Intel ME VSCC Table Base Address (VTBA): 0x000ef0 ME VSCC table: JID0: 0x004b25bf SPI Component Vendor ID:0xbf SPI Component Device ID 0: 0x25 SPI Component Device ID 1: 0x4b VSCC0: 0x20092009 Lower Erase Opcode: 0x20 Lower Write Enable on Write Status: 0x50 Lower Write Status Required:Yes Lower Write Granularity:1 bytes Lower Block / Sector Erase Size:4KB Upper Erase Opcode: 0x20 Upper Write Enable on Write Status: 0x50 Upper Write Status Required:Yes Upper Write Granularity:1 bytes Upper Block / Sector Erase Size:4KB OEM Section: 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Found Region Section FLREG0:0x Flash Region 0 (Flash Descriptor): - 0fff FLREG1:0x07ff0400 Flash Region 1 (BIOS): 0040 - 007f FLREG2:0x03ff0001 Flash Region 2 (Intel ME): 1000 - 003f FLREG3:0x0fff Flash Region 3 (GbE): 00fff000 - 0fff (unused) FLREG4:0x0fff Flash Region 4 (Platform Data): 00fff000 - 0fff (unused) Found Component Section FLCOMP 0x0010001c Dual Output Fast Read Support: not supported Read ID/Read Status Clock Frequency: 20MHz Write/Erase Clock Frequency: 20MHz Fast Read Clock Frequency: 20MHz Fast Read Support: supported Read Clock Frequency:20MHz Component 2 Density: 4MB Component 1 Density: 8MB FLILL 0x Invalid Instruction 3: 0x00 Invalid Instruction 2: 0x00 Invalid Instruction 1: 0x00 Invalid Instruction 0: 0x00 FLPB 0x Flash Partition Boundary Address: 0x00 Found PCH Strap Section PCHSTRP0 : 0x00205602 PCHSTRP1 : 0x010f PCHSTRP2 : 0x9000 PCHSTRP3 : 0x PCHSTRP4 : 0x00c8e000 PCHSTRP5 : 0x PCHSTRP6 : 0x PCHSTRP7 : 0x PCHSTRP8 : 0x PCHSTRP9 : 0x PCHSTRP10 : 0x00010044 PCHSTRP11 : 0x9997 PCHSTRP12 : 0x PCHSTRP13 : 0x PCHSTRP14 : 0x PCHSTRP15 : 0x000e AltMeDisable bit is not set Found Master Section FLMSTR1: 0x (Host CPU/BIOS) Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled Platform Data Region Read
[coreboot] Cisco Meraki use coreboot in some MX products and will not provide the source code
Hello, Several Cisco Meraki products (MX84, MX250) are using the coreboot bootloader. Meraki are also distributing coreboot builds for these products via their update mechanism. In October 2021, I requested the corresponding coreboot source code for the MX84 from open-sou...@meraki.com. Another individual requested the coreboot source code for the MX250 around the same time. We own the devices in quesiton. To date, Meraki have not provided the source code or provided an explanation as to the delay in providing the source code. The last reply I received was in January, and they have not replied to any of my follow up requests. As coreboot is GPL licensed software, I wanted to inform the coreboot community that I believe Cisco Meraki are not acting in good faith and are, in my opinion, violating the GPL by not providing the coreboot source code upon request. Kind regards, Hal Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Support #387] Support Framework Laptop
Issue #387 has been updated by Martin Roth. Hey Jun, Please don't misunderstand any of this as hostility - it's definitely not meant that way. I think we all would like a framework coreboot port, and would be excited to see it happen, but it takes quite a bit of work to get an initial port done and maintained. As a member of the coreboot community, I want to make sure that any issues in this process don't come back onto the community for any inadequacies of any work that's being done. The coreboot project is developed both by individuals and companies using it for their own needs. Those companies invest a significant amount to get that work done, and any work done by individuals is done on their own time. We care intensely about the project, and keeping things running smoothly takes a very significant amount of work on our part. Any work that is done or promised by the people that have been supplied framework machines is being done as individuals, not as direct representatives of the coreboot project as a whole. As far as fundraising to do a port, that is also something that would need to be done by individuals, not by the coreboot project. We have a number of different consulting companies who work on coreboot, and as a project, we're not going to discriminate between them by doing an official "coreboot" fundraiser for a particular project. We as a project will absolutely support anyone doing a fundraiser, but any expectations of deliverables need to be understood as being between the developers doing any paid work and the people contributing to that effort. The coreboot project is not a party to the transaction and cannot be held responsible for any failures, beyond trying to fix any normal breakages in ongoing development of the coreboot codebase. Again, I very much appreciate the desire to have a coreboot port for the framework laptop, and I'm sure that something will be done at some point/ I just want everyone involved to have realistic expectations of how development works and how the platform would be maintained. Thanks for setting this up as a place for a discussion to happen. Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387#change-951 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the > coreboot community. Our plan in the near term is to help them create a shim > loader that can be signed to run on any Framework Laptop, which then enables > anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Support #387] Support Framework Laptop
Issue #387 has been updated by Martin Roth. Can we find out who the framework laptops were supplied to? It's great that these individuals have agreed to work on the port, but the coreboot community as a whole hasn't signed up to support the framework laptop. There are a number of professional consulting groups that do coreboot ports. If framework is actually interested in getting a port done, might I suggest that these might be a better way to go about getting a port done? https://www.coreboot.org/consulting.html Support #387: Support Framework Laptop https://ticket.coreboot.org/issues/387#change-948 * Author: Jun Aruga * Status: New * Priority: Normal * Category: board support * Target version: none * Start date: 2022-06-05 * Affected hardware: Framework Laptop Dear coreboot developers, I am a user of Framework Laptop[1][2]. Thank you for working to make coreboot work on Framework Laptop! This ticket is to track the task, as I didn't see any other issue tickets about Framework Laptop here. According to the Framework founder's comment[3] below, Framework provided Framework Laptops to the coreboot community. > We've handed three systems that can boot unsigned bootloaders to folks in the > coreboot community. Our plan in the near term is to help them create a shim > loader that can be signed to run on any Framework Laptop, which then enables > anyone to do further coreboot development. Then I saw Matthew's try to make the coreboot work on Framework Laptop,[4] but unfortunately it didn't work at that time.[5] How is the current status? What prevents coreboot from working on the Framework Laptop? How can we, people in the Framework community, help you? As a reference, there is a coreboot specific thread on the Framework community forum.[6] ## References * [1] https://frame.work/ * [2] Framework Computer - Wikipedia - https://en.wikipedia.org/wiki/Framework_Computer * [3] Framework Laptop Mainboard, Hacker News, April 20, 2022 - https://news.ycombinator.com/item?id=31097434 * [4] Matthew tries to port Coreboot to the Framework laptop - February 27, 2022 - https://www.youtube.com/watch?v=Jf_6xW-8tfQ * [5] Matthew Garrett on Twitter, February 27, 2022 - https://twitter.com/mjg59/status/1497788538212917250 * [6] Free the EC! and Coreboot Only - https://community.frame.work/t/free-the-ec-and-coreboot-only/791 -- 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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Removing Yabits as a payload - Now, or after 4.19 release?
Unfortunately, yabits hasn't really seen any updates since it was added as a payload, so I think it's time to remove it. If there's no objection, we can remove it as a payload after today's 4.17 release. I don't believe this counts as deprecation, but if others feel otherwise, we can announce it in the 4.17 release notes (I'm working on those, I swear) and release it after the 4.19 release. Let me know what you think, either about the timing or about removing it period. As always, if it sees a reassurance in work, we can bring it back. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: How to register on Coreboot Mainboard Vendor
Hi He Chen, You are absolutely welcome to use coreboot on your devices if your CPU is supported. What processor are you using? There's no specific requirement to become a coreboot vendor except to sell devices with coreboot on them, and to email us to let us know so we can add your company to the website. Since your team has already designed the hardware, you may have the knowledge needed to do a coreboot port for your board. If you need some help, please reach out to one of the companies on the consultants page on our website: https://coreboot.org/consulting.html Take care Martin May 23, 2022, 07:54 by heche...@hotmail.com: > Dear Coreboot team, > Good days. We are an OEM Firewall mini pc manufacturer in SHENZHEN China. > We are developing 2.5G firewall Mini PC hareware(we already finished them). > And as Coreboot is very poweful and well knowned in firewall field so we are > wonding that if we can become a coreboot registered motherboard vendor so > user could use coreboot on our devices. May we know how to achieve its > requirements ? > > Waitng for your comments and thanks a lot. > > Best Regards > He Chen > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [Proposal] Drop support for Ice lake [unmaintained]
This didn't get any discussion when it was initially posted, so I want to make sure there are no objections. I'll post the notice of the removal in the 4.17 release notes unless there's a reason to keep Ice Lake code around. This will be removed from the master branch after the 4.19 release. Martin Jan 4, 2022, 12:33 by coreboot@coreboot.org: > Good day folks, > > In a recent change[0], it was proposed that we drop support for the Intel Ice > Lake platform. > The only mainboard supporting the platform was the Intel RVP, but as far as > anyone knows, > it appears the project never progressed past the initial silicon, and so the > code is now > unmaintained and also unused. Since Ice Lake is very similar to TGL & ADL, it > poses a > maintenance burden when dealing with Intel common code e.g., anything in > src/soc/intel/common. > > According to [1], this should be announced in upcoming release notes first, > and removal > could happen in 6 months. > > Wondering if anyone has any thoughts on why we should keep it around, > otherwise let's update the upcoming release notes to give the "official" > notice > that it will be dropped. > Cheers, > - Tim > > [0]> https://review.coreboot.org/c/coreboot/+/60053 > [1]> https://doc.coreboot.org/releases/templates.html > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Please test and review AGESA code
Sorry, I guess I'm just sensitive about the topic of removing code, since, as you say, it's been talked about a lot. I obviously do appreciate your work on it. Take care. Martin May 17, 2022, 12:17 by art...@aheymans.xyz: > Hi > I have patches that improve those platforms and wrote code that should make > some of > the AGESA platforms easier to transition to newer soon to be mandated > codepaths and I did so > with past codepath mandates with both code and review. > > My message about moving code from the master branch was more or less a tongue > in cheek, I'm > sorry that it was perceived differently. I'm not advocating for removal, just > referring to past discussions. > It is however a problem to get code changes tested. The (admittedly cynical) > joke was just to get some attention to patches > I would like to get reviewed as that work tends to be related to general > codebase improvements. > > > Instead of phrasing it this way, maybe say something like, "Thanks AMD for > > releasing this, now community, let's get together and review and improve > > things." > It's likely that AMD does not care about the AGESA platforms supported in > coreboot, since they don't produce that hardware anymore? > Just making assumptions here. Anyway, improving that code is my intention > given that I write patches for it ;-) > > Arthur > > On Tue, May 17, 2022 at 7:40 PM Martin Roth <> gauml...@tutanota.com> > wrote: > >> Arthur, you are not making an argument that any vendor should release their >> source code as opensource. I agree that all of this code should be >> reviewed, but if we complain about code quality and lack of testing for open >> sourced code, but don't for closed source, that's an argument against any >> company opening their codebases. >> >> Instead of phrasing it this way, maybe say something like, "Thanks AMD for >> releasing this, now community, let's get together and review and improve >> things." >> >> Just my opinion, and I'm intentionally replying off list. But I'll say >> that I'm going to fight *very* hard to keep the AGESA codebases in coreboot >> for as long as there are people testing it. Doing otherwise is again, a >> disincentive to companies for opening their sourcecode. >> >> Take care. >> Martin >> >> >> May 17, 2022, 08:47 by >> art...@aheymans.xyz>> : >> >> > Hi >> > We spend more time debating whether to keep AGESA in the master branch >> than actually reviewing code to maintains it. >> > Here are some patches series I would like to be tested & reviewed: >> > Agesa was never properly linked and relied on default linker behavior to >> append unmatched data. Here is the fix: > >> >> https://review.coreboot.org/q/topic:AGESA_DATA >> > Use MRC cache for non volatile data > >> >> https://review.coreboot.org/q/topic:AGESA_MRC_CACHE >> > Use CLFLUSH to make sure code hits DRAM and incidently avoid inconsistent >> MTRRs (bonus is compressed postcar stage): > >> >> https://review.coreboot.org/q/topic:compress_postcar >> > Kind regards >> > Arthur >> > >> >> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Please test and review AGESA code
May 17, 2022, 11:40 by coreboot@coreboot.org: > Just my opinion, and I'm intentionally replying off list. > Oops. Or not. :-/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Please test and review AGESA code
Arthur, you are not making an argument that any vendor should release their source code as opensource. I agree that all of this code should be reviewed, but if we complain about code quality and lack of testing for open sourced code, but don't for closed source, that's an argument against any company opening their codebases. Instead of phrasing it this way, maybe say something like, "Thanks AMD for releasing this, now community, let's get together and review and improve things." Just my opinion, and I'm intentionally replying off list. But I'll say that I'm going to fight *very* hard to keep the AGESA codebases in coreboot for as long as there are people testing it. Doing otherwise is again, a disincentive to companies for opening their sourcecode. Take care. Martin May 17, 2022, 08:47 by art...@aheymans.xyz: > Hi > We spend more time debating whether to keep AGESA in the master branch than > actually reviewing code to maintains it. > Here are some patches series I would like to be tested & reviewed: > Agesa was never properly linked and relied on default linker behavior to > append unmatched data. Here is the fix: > > https://review.coreboot.org/q/topic:AGESA_DATA > Use MRC cache for non volatile data > > https://review.coreboot.org/q/topic:AGESA_MRC_CACHE > Use CLFLUSH to make sure code hits DRAM and incidently avoid inconsistent > MTRRs (bonus is compressed postcar stage): > > https://review.coreboot.org/q/topic:compress_postcar > Kind regards > Arthur > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: [RFC] #pragma once
After reading what I've included below, I'm going to have to vote to keep the guards. Martin May 16, 2022, 10:59 by david.hendri...@gmail.com: > On Mon, May 16, 2022 at 8:59 AM ron minnich wrote: > >> >> btw, sometimes this has gone the other direction .. >> https://github.com/lowRISC/opentitan/pull/5693 >> > > It looks like they did that solely to conform to Google's style guide > which, dogmatic as it may appear, makes sense since OpenTitan is a > Google-lead project. > The question then is 'why does Google require the use of guards?'. Whatever you think of google, they're not going to mandate something like this without a good reason. I went searching for where this rule came from, and found this: ``` If you trust our in-house C++ compiler gurus, here's the most salient part of the whole thread linked above.Matt Austern (4/11/2013): If you talk to the authors of [most C++] compilers, I think you'll find that most of them consider "#pragma once" (or the equivalent #import) to be a flaky feature -- something that works almost all of the time and that can cause seriously annoying bugs when it doesn't work. Chandler Carruth (4/12/2013): As one of the authors of one of those compilers, I couldn't agree more. ``` any interested Googlers can find this here: https://yaqs.corp.google.com/eng/q/5768278562045952 Further digging: ``` To support #pragma once, the compiler tries to identify duplicate encounters with the same file, but the check gcc actually performs to establish the identity of the file is weak. Here's someone who made two copies of the same header with different names, each with a #pragma once, and it screwed up his build. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 The two headers had the same size, same content, and same timestamps because he had run "touch *" on them, but they were intended to both be included. Only one was included, and the other was falsely identified as a re-inclusion and ignored.One might say he was asking for trouble by running "touch *", but timestamp collisions are EASY to come by. First of all, they're only 1sec resolution. You might patch all the relevant files and they'd have matching timestamps. You might be using a network filesystem that just doesn't bother with timestamps (common). ``` Now both of these are almost a decade old, so things might have changed quite a bit since then. Linux kernel threads: https://lkml.iu.edu/hypermail/linux/kernel/1401.0/02048.html https://lore.kernel.org/lkml/CAHk-=wi54descexxpmro+q2nag_tup+y5ybhc_9_xglerfp...@mail.gmail.com/ ``` On Sun, Feb 28, 2021 at 11:34 AM Alexey Dobriyan wrote:>> >> > End result: #pragma is fundamentally less reliable than the> > traditional #ifdef guard. The #ifdef guard works fine even if you> > re-read the file for whatever reason, while #pragma relies on some> > kind of magical behavior.You continue to not even answer this very fundamental question."#pragma once" doesn't seem to have a _single_ actual real advantage.Everybody already does the optimization of not even opening - muchless reading and re-parsing - headers that have the traditional #ifdefguard.And even if you _don't_ do that optimization, the #ifdef guardfundmentally semantically guarantyees the right behavior.So the #ifdef guard is (a) standard (b) simple (c) reliable (d) traditionaland you have yet to explain a _single_ advantage of "#pragma once".Why add this incredible churn that has no upside?So no. We're not using #pragma once unless y9ou can come up with somevery strong argument for itAnd no, having to come up with a name for the #ifdef guard is not astrong argument. It's simply not that complicated. Linus ``` ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] coreboot 4.17 release planned for May 30th
The next quarterly release, 4.17 is targeted for May 30, 2022. Additionally, at that time, we plan to update the release packages and version numbers any of the coreboot branches which have been modified since they were released. Going forward, this should happen anytime there's a new release. Please test any boards that you have available. Current stats since the 4.16 release, 3 months ago (As of early Monday, May 16): Added 10 mainboards: --- * Clevo L140MU / L141MU / L142MU * Dell Inc. Dell Precision T1650 * Google -> Craask * Google -> Gelarshie * Google -> Mithrax * Google -> Osiris * HP Z220 CMT Workstation * Star Labs Star Labs LabTop Mk IV (i3-10110U and i7-10710U) * Star Labs Star Labs Lite Mk III (N5000) * Star Labs Star Labs Lite Mk IV (N5030) Removed 2 mainboards: --- * Google -> Deltan * Google -> Deltaur repo statistics --- - Total Commits: 998 - Average Commits per day: 12.58 - Total lines added: 34473 - Average lines added per commit: 34.54 - Number of patches adding more than 100 lines: 40 - Average lines added per small commit: 22.35 - Total lines removed: 57663 - Average lines removed per commit: 57.78 - Total difference between added and removed: -23190 - Total authors: 131 - New authors: 17 Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Intel Quark - a quick update
Thanks Andy, I think that's totally reasonable. Martin Apr 26, 2022, 06:56 by andy.p...@sdcsystems.com: > Felix wrote... > > >So, will you also step up as a maintainer for it? > I’m going to reserve judgement on that until I see how things go with > trying to get the existing coreboot code running on the boards. The Gen > 1 should be here tomorrow (I think). > > -Andy. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Here's a list for coreboot. https://review.coreboot.org/c/coreboot/+/63797 Martin Apr 22, 2022, 18:46 by rminn...@gmail.com: > oh oops the person doing that misunderstood me, we'll have to fix it > > On Fri, Apr 22, 2022 at 5:41 PM Martin Roth wrote: > >> >> Hey Ron, >> I think this is a good plan. We can make a markdown file doing the same. >> I'm not sure that coreboot wants to record where it's deleted, but instead >> the branch where it would be maintained. >> This is the solution I was talking about in the coreboot leadership meeting: >> https://review.coreboot.org/c/coreboot/+/63754 >> >> Take care. >> Martin >> Apr 22, 2022, 17:24 by rminn...@gmail.com: >> >> > The discussion here has been pretty helpful to my thinking. I think >> > the concerns people are raising are important. >> > >> > We are deprecating ALL boards on oreboot that need FSP, as we took the >> > decision a few weeks ago to drop boards >> > that require blobs on the main CPU (we're accepting PSP blobs for now) >> > >> > This leaves two x86 boards behind, not counting qemu. >> > >> > But, based on what has come up here, we decided we did not want to >> > leave all memory of old efforts behind. >> > >> > This is the result: https://github.com/oreboot/oreboot/pull/570/files >> > >> > Not sure if this would be desired for coreboot, but I am mentioning it >> > here for reference. >> > >> > Thanks >> > >> > ron >> > >> > On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper wrote: >> > >> >> >> >> (I'm not a Coreboot dev/maintainer, so apologies for commenting from the >> >> peanut gallery...) >> >> >> >> >> >> On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote: >> >> > [...] >> >> > 2) Decide on a set of criteria that we can use to evaluate whether or >> >> > not things should be removed from the master branch and maintained on >> >> > a release branch. >> >> >> >> Makes sense. >> >> >> >> >> >> > Currently, the only reason we have specified that a platform will be >> >> > moved to a release branch is if it's hindering progress. Basically if >> >> > it's not using an API we want to mark a required, or using code that >> >> > is being deprecated. >> >> > >> >> > If hindering progress is the only reason that something should ever be >> >> > removed from the master branch, I'm fine with that. Let's decide that >> >> > and document it so we don't have to have this discussion in the >> >> > future. >> >> >> >> Surely there will sometimes be platforms/chips that, for good reason, >> >> the community wants to keep in master - even if this would mean rewrites >> >> for those platforms/chips re the two matters you mentioned above: >> >> >> >> a. not using APIs that future versions of coreboot will require; >> >> >> >> b. using code that is being deprecated? >> >> >> >> >> >> Such "good reasons" could include that the plaform/chip: >> >> >> >> 1. is in widespread use with coreboot, even if long out of production >> >> (e.g. certain server boards or Thinkpad models); or >> >> >> >> 2. is targeted by related projects (e.g. Heads) that coreboot >> >> developers would prefer to avoid unnecessarily inconveniencing; or >> >> >> >> 3. has active coreboot testers/maintainers able to integrate relevant >> >> updates, and is passing all significant CI tests. >> >> >> >> >> >> > Other options we could look at: >> >> > >> >> > - A platform has not been sold in X years. >> >> > >> >> > - A chip has not been produced for X years. >> >> >> >> I can see the appeal of these criteria: they are easy to define. >> >> However, they are probably not wise criteria, as they may conflict with >> >> one or more of the "good reasons" above, especially reason 1. >> >> >> >> >> >> > - A platform has not been tested in X years. >> >> > >> >> > - A platform hasn't had an active maintainer for X years. (Maybe the >> >> > maintainer should be asked to test a platform as well?) &g
[coreboot] Re: Deprecation of the Intel Quark SoC
Hey Ron, I think this is a good plan. We can make a markdown file doing the same. I'm not sure that coreboot wants to record where it's deleted, but instead the branch where it would be maintained. This is the solution I was talking about in the coreboot leadership meeting: https://review.coreboot.org/c/coreboot/+/63754 Take care. Martin Apr 22, 2022, 17:24 by rminn...@gmail.com: > The discussion here has been pretty helpful to my thinking. I think > the concerns people are raising are important. > > We are deprecating ALL boards on oreboot that need FSP, as we took the > decision a few weeks ago to drop boards > that require blobs on the main CPU (we're accepting PSP blobs for now) > > This leaves two x86 boards behind, not counting qemu. > > But, based on what has come up here, we decided we did not want to > leave all memory of old efforts behind. > > This is the result: https://github.com/oreboot/oreboot/pull/570/files > > Not sure if this would be desired for coreboot, but I am mentioning it > here for reference. > > Thanks > > ron > > On Mon, Apr 18, 2022 at 11:05 AM Sam Kuper wrote: > >> >> (I'm not a Coreboot dev/maintainer, so apologies for commenting from the >> peanut gallery...) >> >> >> On Mon, Apr 18, 2022 at 04:32:36AM +0200, Martin Roth wrote: >> > [...] >> > 2) Decide on a set of criteria that we can use to evaluate whether or >> > not things should be removed from the master branch and maintained on >> > a release branch. >> >> Makes sense. >> >> >> > Currently, the only reason we have specified that a platform will be >> > moved to a release branch is if it's hindering progress. Basically if >> > it's not using an API we want to mark a required, or using code that >> > is being deprecated. >> > >> > If hindering progress is the only reason that something should ever be >> > removed from the master branch, I'm fine with that. Let's decide that >> > and document it so we don't have to have this discussion in the >> > future. >> >> Surely there will sometimes be platforms/chips that, for good reason, >> the community wants to keep in master - even if this would mean rewrites >> for those platforms/chips re the two matters you mentioned above: >> >> a. not using APIs that future versions of coreboot will require; >> >> b. using code that is being deprecated? >> >> >> Such "good reasons" could include that the plaform/chip: >> >> 1. is in widespread use with coreboot, even if long out of production >> (e.g. certain server boards or Thinkpad models); or >> >> 2. is targeted by related projects (e.g. Heads) that coreboot >> developers would prefer to avoid unnecessarily inconveniencing; or >> >> 3. has active coreboot testers/maintainers able to integrate relevant >> updates, and is passing all significant CI tests. >> >> >> > Other options we could look at: >> > >> > - A platform has not been sold in X years. >> > >> > - A chip has not been produced for X years. >> >> I can see the appeal of these criteria: they are easy to define. >> However, they are probably not wise criteria, as they may conflict with >> one or more of the "good reasons" above, especially reason 1. >> >> >> > - A platform has not been tested in X years. >> > >> > - A platform hasn't had an active maintainer for X years. (Maybe the >> > maintainer should be asked to test a platform as well?) >> >> These seem much better criteria. >> >> To make them easier to apply, should coreboot comprehensively track, for >> platforms/chips (roughly as Debian does for packages): >> >> - the current maintainer(s) for that platform/chip, >> >> - the current tester(s) for that platform/chip, >> >> - when that platform/chip was last tested, and >> >> - what the test results were? >> >> I think coreboot already tracks some of this data via >> https://lava.9esec.io or https://qa.coreboot.org/ - I'm not certain. >> >> That being so, I propose some draft policy wording (please >> change/improve...): >> >> "For any given platform or chip that has ever been targeted by the >> coreboot project: >> >> - For each coreboot "version" (point release, master, or >> hardware-specific branch): >> >> - if the platform/chip has been tested on that version, but >> the test was unsuccessful, the platform/chip shall be >> labelled
[coreboot] Re: 2022-04-20 - coreboot Leadership meeting minutes
Apr 20, 2022, 14:49 by coreboot@gmail.com: > # 2022-04-20 - coreboot Leadership > > ## Decisions > * Martin will do an example of Kconfig where the platforms have been removed > keep the mainboard names in the tree. When selected, it will show the branch > where the platform is maintained. We can also include the last known good > commit for current mainboards. > Please take a look at the proof of concept patch I've posted at coreboot.org and let me know what you think. The code's not much to look at - it's better to actually test it. https://review.coreboot.org/c/coreboot/+/63754 This is supposed to address the issue that after a board has been moved to a branch, it's basically dead. By keeping the boards in the master branch's Kconfig and showing the user what to check out, hopefully this should simplify that issue. It's not a complete solution, but hopefully it's seen as a step in the right direction. Take care,Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Apr 16, 2022, 08:03 by nic...@gmx.de: > It's always a trade-off. Is the Quark code really that bad that it > is hard to keep it along? > I'm not particularly looking at removing the Quark code right now. I lobbied early on to keep it in the tree. Really, I want 2 things out of this discussion. 1) Make it less harmful to move things to a release branch for maintenance. - After talking to Peter, this could be as simple as keeping the mainboard in the Kconfig with a hash that should be checkout out to build that board.2) Decide on a set of criteria that we can use to evaluate whether or not things should be removed from the master branch and maintained on a release branch. From past experience, we should be realistic and admit that platforms will eventually get moved out of the master branch at some point. If Quark isn't removed now, at some point, 3, 5, or 10 years from now, it's going to get removed from the master branch. As Ron mentioned, keeping platforms in master does have a cost. - The cost of testing isn't really all that high, but it's there. - The cost of maintaining the platform in the tree could also be an issue. That's the cost that Felix was looking at that started this discussion - he founds some code that was required for the quark platforms that he thought should be removed. - From Arthur's email about lb_serial - keeping platforms in the tree may require us to keep old workarounds in place. Currently, the only reason we have specified that a platform will be moved to a release branch is if it's hindering progress. Basically if it's not using an API we want to mark a required, or using code that is being deprecated. If hindering progress is the only reason that something should ever be removed from the master branch, I'm fine with that. Let's decide that and document it so we don't have to have this discussion in the future. Other options we could look at:- A platform has not been sold in X years. - A chip has not been produced for X years. - A platform has not been tested in X years. - A platform hasn't had an active maintainer for X years. (Maybe the maintainer should be asked to test a platform as well?) Hopefully, if we can make it easy enough to maintain a platform on a release branch, it won't be so much of an issue in the future, but it'd still be nice to have some criteria that we can agree on for when to move things. Thanks everyone. As always, I'm not trying to argue with anyone, just looking to get an actual decision of some sort out of this thread. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Apr 16, 2022, 08:32 by nic...@gmx.de: > Hi Sheng, > > On 16.04.22 11:01, Sheng Lean Tan wrote: > >> Personally I think moving Galileo soc to stable branch is a win-win >> situation for all of us. >> > > it looks like nobody is maintaining such a stable branch yet. Would you > volunteer to maintain one for Quark? AIUI, some people already want to > take care of testing. So you'd only have to maintain compatibility with > newer toolchain and payload versions and such. > The stable branches that Sheng refers to are the release branches. We've had a number of updates on the 4.11 branch. We've now got "stable" release branches for the 4.11, 4.12, 4.14, 4.15 & 4.16 releases. There is a jenkins branch build that should build patches to any of the branches. I think everything's taken care of for these release branches, although we need to update the release checklist to make a new release of any patches pushed to these branches since the last release cycle. I'll handle that on the next release. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Testing coreboot mainboards
Hey Jack, no problem, let's start a new thread. Apr 14, 2022, 14:56 by jrose...@chromium.org: > Hoping I'm not derailing too far here: Could we consider modeling this based > on > http://appdb.winehq.org> ? I.e., people can contribute test results per > board, and upload things like "which commit hash did you build with", "what's > your .config", etc? > > We could even consider plumbing that into the build system. "make > submit_test_result" perhaps ;) > We've got the util/board_status.sh script that uploads some information into a git repo. If you want to see the repo:git clone "https://review.coreboot.org/board-status; That updates this page: https://coreboot.org/status/board-status.html The git repo was never meant to be a permanent solution and has gotten to be quite large. This is another project that we'd love to have more help with. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Apr 14, 2022, 14:06 by 0xl...@gmail.com: > Hi Martin, > >> I think we all agree that it'd be good to have test racks that have all of >> the boards in the coreboot repository for verification, however that's >> currently not practical with the resources we have. The whole thing just >> isn't a simple problem to solve. >> > > Often the biggest impediment to something like this is simply holding it as a > shared goal, and continuing to do so when issues arise. > > If public test labs were desired, a callout for donations of space and > hardware could be placed on the main page. If somebody had the capacity to do > more than that, then local makerspaces and hackerspaces could be reached out > to. > It's a good point. Maybe we can put up a webpage with how an individual can help the coreboot project. Put up a list of boards to be adopted for testing and how to find which commit broke them if they're broken. >> I'm actually also not completely convinced that just testing the boards is >> the solution to whether or not we keep a board/chip on the mastre branch. >> If there really aren't any people using coreboot on their quark boards, then >> personally, I don't see any need to keep it in the master branch. I know >> others feel differently, but as I said earlier in this thread, I don't think >> there's actually any harm in moving an aging or little-used platform to be >> maintained on a branch. >> > > Sounds like there is a difference of opinion in the community. > Always. ;-) > It seems obvious to me that there would be people using coreboot on their > quark boards. The world is gigantic. > > But you have a different opinion, which is fine. > > It seems to me the reason to include a board is because people care about > doing so. > Agreed. Currently we have no way of knowing whether or not anyone cares about a board. There are two ways people typically make it known - by working on a board or by testing a board. > I care enough about including boards that I'd test this one if it was needed > to do so to retain it. But I'm just a visitor. And it seems more productive > to discuss public test labs that could grow to support more boards. > Sure, and I'm not trying to advocate that we remove anything. Mostly right now I'm trying to figure out how we should decide when things should or should not be moved to a branch to make it easier going forward. Take care Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Apr 14, 2022, 14:18 by 0xl...@gmail.com: > I'm sending an email directly to the board committer since nobody has > mentioned the history and is responding to my idea a lot. > Lee, do you still have your quark galileo board? Are you at all able to test > a new build or package equipment to mail to a volunteer? > > On Thu, Apr 14, 2022, 4:13 PM ron minnich <> rminn...@gmail.com> > wrote: > >> do you have a way to recover if the flash fails? >> >> On Thu, Apr 14, 2022 at 1:09 PM Andy Pont <>> andy.p...@sdcsystems.com>> > >> wrote: >> > >> > Karl wrote… >> > >> > >Obviously a way to sidestep all this would be to simply test the board >> > >in question, which is a small investment of money and time. >> > There is still one of these boards (Intel Galileo) available on eBay >> > here in the UK. I can likely commit the time to test coreboot on that >> > board but don’t have the money spare to purchase it due to the ongoing >> > cost of living crisis here. >> > >> > If someone wants to purchase and donate the board, I can have a look at >> > how coreboot is on it. >> > >> > -Andy. >> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs
Apr 12, 2022, 10:25 by insu...@riseup.net: > > On 4/12/22 10:17, Nico Huber wrote: > >> Hello Insurgo, >> >> On 12.04.22 16:01, Insurgo Technologies Libres / Open Technologies wrote: >> >>> On April 12, 2022 8:55:56 AM UTC, Arthur Heymans >>> wrote: >>> >>>>> Would it make sense to backport your fix to old releases and bump >>>>> those release numbers to a .1 on the end? >>>>> >>>> Some see releases as mere synchronization tags & nice PR. >>>> Some releases are also branches in gerrit but there are none affected by >>>> this (latest is 4.12 and it was introduced in 4.13). >>>> >>> As you may know, coreboot distributions (talking of Heads specifically >>> here), take releases tarballs and apply patches where needed on top of it. >>> >>> In the present case, Heads currently depends on coreboot 4.11, 4.13 and >>> 4.15 for its supported boards. I quickly attempted to backport the relevant >>> patches to 4.13 tarball release, unsuccessfully. >>> >> have you checked if the SMM module loader v2 was used in your 4.13 >> builds? AIUI, it was optional and only enabled on user request. >> > > Thanks Nico for that pointer. Community maintained Heads boards are mostly > based on coreboot 4.13 as of now: > >> # CONFIG_X86_SMM_LOADER_VERSION2 is not set >> > > was hidden in the savedefconfig format stored under Heads repositories for > coreboot 4.13 depending boards. > > > > Expending the saved configuration confirms non-usage of SMM2 optional loader > and is therefore not considered vulnerable per reported vulnerability. > > > > I would highly doubt other coreboot based distributions would have activated > this explicitly, but will depend of the new coreboot pushed defaults from > upstream releases. Let's see. > > 4.15 and 4.16 removed that optional configuration setting (default > configuration) and seemed to have switched to SMM2 by default. > > Neither coreboot 4.14, 4.15 or 4.16 releases notes explicitly noted the > change to SMM2, where 4.13 announces the change. Not sure users are following > coreboot discussions, but I hope coreboot distribution maintainers are. > > Consequently, all downstream coreboot based distributions, and their users, > may stay vulnerable if no new 4.15.1 4.16.1 are released from my > understanding until 4.17 is released. > I definitely agree that it would be a good thing to create the release branches for 4.14, 4.15, and 4.16 and port at least these security changes, then do a .1 release with those updates, and remove the original tarballs from our download page. Even if this isn't needed for a particular project like Heads, I think it's our responsibility to go back and fix security issues like this. I'll see what I can do to make this happen. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Apr 13, 2022, 06:10 by 0xl...@gmail.com: > On Wed, Apr 13, 2022, 6:26 AM Patrick Georgi <> patr...@coreboot.org> > wrote: > >> Am 12.04.2022 um 23:54 schrieb Karl Semich: >> > Obviously a way to sidestep all this would be to simply test the board >> > in question, which is a small investment of money and time. >> I appreciate that you volunteer to do that for Quark. Can't be too bad, >> it's a small investment of money and time, after all. >> > > Sorry, have I offended you? What is it you read me as saying? > > Does this seem lengthy or expensive to you? > Hi Karl, I don't think Patrick felt offended or even meant to offend. Unfortunately, there's been a lot of "Well, coreboot could just..." without a good explanation of how such a thing gets accomplished with the resources we have available to us. Patrick was a little short, but we'd honestly love to have someone offer to take up a task like testing a board or two, but the suggestion usually seems to be that it should just get added to our (already overflowing) plates. You're right that testing a single board isn't a huge amount of work, but it definitely consumes resources. We need space, power, internet, the device to test, time to set the test device up, a hardware flash tool, a server to communicate with the test device, and a person to fix any issues when something breaks. I think we all agree that it'd be good to have test racks that have all of the boards in the coreboot repository for verification, however that's currently not practical with the resources we have. The whole thing just isn't a simple problem to solve. I'm actually also not completely convinced that just testing the boards is the solution to whether or not we keep a board/chip on the mastre branch. If there really aren't any people using coreboot on their quark boards, then personally, I don't see any need to keep it in the master branch. I know others feel differently, but as I said earlier in this thread, I don't think there's actually any harm in moving an aging or little-used platform to be maintained on a branch. If you have thoughts on how we can overcome any of these issues, I'd love to discuss things with you further. Take care. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
Apr 12, 2022, 12:14 by f...@mniewoehner.de: > On Mon, 2022-04-11 at 22:23 +, Peter Stuge wrote: > >> Martin Roth via coreboot wrote: >> > 1) Please don't use the term deprecate - use "moved to a branch" >> >> I don't think the wording matters, my points are discoverability and >> drive-by maintainance. >> Yes, wording matters. Opinions are changed in politics by just reframing the argument all the time. If you really don't think that wording matters check out this article, and the book that it's about: https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-elephant/ Every time coreboot says that some platform is being "deprecated", it starts an argument. I'd really like to avoid that argument. >> > If a platform is perfect and doesn't need to be updated, it doesn't >> > need to be on the master branch, right? >> >> I think wrong, because being on master is the only chance to receive >> tree-wide changes, e.g. through coccinelle spatches or sed:its. >> >> Missing those rots the code quicker so yes, something getting moved >> to a non-master branch is de-facto deprecation by degradation to >> second class. >> How can it degrade if it's not being changed? Older platforms that aren't being tested regularly stop working *because* they're in the main branch, receiving lots of code changes without being tested. By moving them to a branch, they're less likely to get additional breaking fixes. So allowing them to be maintained on a branch is much better for stability. It's absolutely not second class either. If people understand that the older platforms are maintained on these version branches, they can be worked on there without having all of the changes on newer platforms to deal with. It's a matter of getting people used to working on those older branches. > Maintaining without ability to test will make it degrade, too. > Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment. >> > I absolutely agree that if something isn't being used, it doesn't >> > need to be maintained on the master branch. >> >> I disagree. >> Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch. If it's not being used, it can just as easily not be used on a release branch as the master branch, and then we don't have to continue to try to maintain it as the rest of coreboot moves forward. >> > I just want to make sure that things actually aren't being used >> > before moving them to a branch. >> >> I think "no usage" alone should be a very weak motivator to move >> something from master, just like "no availability". >> >> (Many SOCs are currently unavailable and will remain so for some time!) >> > Why > It's not unavailable for *some time* but forever, bc it's not being produced > anymore. > > >> If code is perfect or nearly perfect then why move it? >> Even if the code was "perfect" when it was written, it doesn't exist in a vacuum. As the rest of the coreboot platform changes around it, the perfect code can stop working. >> >> If there are *concrete* issues with code then I think it would be >> reasonable for *that* to count much more than "no/unknown usage", >> but the current proposal did not reference any such issues, Paul's >> ask didn't yield any and neither did mine. >> > > Not used => not tested. > And how do we know whether or not there are concrete issues with it if it's not being tested? Thanks for the discussion. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Memtest 86+ fork
Hey Mike, Sameer, Sorry, I'd missed this thread until now. I've got a patch train that rebases all of of the coreboot patches onto the latest official memtest86+ version. I can upload that as a branch. I'm currently working on doing the reverse, and making patches to push into the coreboot repo to update the coreboot repo master branch to match the other branch. Martin Jan 29, 2022, 09:27 by mikeb...@gmail.com: > I guess this work is still needed, seeing only these recent changes at > "Memtest86+ fork" repository - > https://review.coreboot.org/q/project:memtest86plus . > Another thing which I guess may be useful, is rebasing the > coreboot-specific "Memtest86+ fork" patches on top of the latest > official Memtest86+ version 5.31b - https://www.memtest.org/#downcode > . CC'ing Patrick Rudolph for more details (since it was his ticket 3 > years ago) > > On Sat, Jan 29, 2022 at 6:43 PM Sameeruddin Shaik > wrote: > >> >> Hi all, >> I wanted to work on below ticket >> >> https://ticket.coreboot.org/issues/184 >> >> Is there anyone working on it. >> Any inputs/hints would be appreciated. >> >> --sameer. >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Deprecation of the Intel Quark SoC
TLDR: 1) Please don't use the term deprecate - use "moved to a branch" 2) Lets set up some rules about moving platforms/chips to a branch. 3) How do we find out what platforms are actually in use? 4) Please don't take this as an argument.We --- First, we are not going to "Deprecate" anything - we are not warning against its use. I'd ask that everyone please stop using that term because it's just too loaded. I understand that the term has been used in coreboot for a while, but let's try to stop using it. What we do is move maintenance of platforms and chips out of the master branch, onto a version branch, but they can always be maintained on or built from that version branch. They can even be moved back into the master branch if desired and if they are brought up to the current standards. We are not deprecating those platforms - they will live on in coreboot as long as we have a git repo that they can be built from. Next, I firmly believe that we need to set up some rules about how long platforms & chips will stay in the coreboot master branch after being introduced, or after they stop being manufactured/sold. Right now, anyone who works to put code into the tree has no way to know when their code will be moved to a branch. Obviously "It's no longer sold" isn't a good reason, because we continue support lots of chips and mainboards that are no longer sold. I think that the argument of "It hasn't been tested in x years" may be valid, but not everyone who uses a platform runs our tests on it. And just because it's being tested may also not reflect that anyone is actually using a platform. Really we have no idea what platforms and chips are actually being used, so it's difficult to determine what should or shouldn't be moved to a branch. Finally, (and apologies to Felix), I hate the argument of getting rid of things simply to "reduce the maintenance burden". If we want to reduce the work that needs to be done to maintain older chips & platforms, let's implement some APIs between things so that there there's a better separation and changes don't affect everything across all of coreboot. If the platform is in the tree, it needs to be supported to the best extent possible, and should be maintained on master as long as it's actually in use. --- My proposals: Let's create some rules about moving platforms & chips to branches to set expectations: - Maybe decide that after being introduced, chips/platforms will stay in the master branch for a minimum of X years unless there's a significant need to remove it. - Maybe say that every SOC/Platform needs a maintainer, and if the maintainer stops responding or working on that platform or doesn't verify that a platform is working, then it will be moved to a branch after X releases / months. If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right? Because we have no way of really knowing what platforms or chips are being used. It might be good to come up with a way to get some metrics regarding this: -- It looks like FWUPD keeps statistics about updates, so maybe that could help, at least for anything that's up there. -- Set up a poll or something for both anonymous and verified users to say what platforms they're using. Right now, this is done solely by the test results, which aren't trivial. -- We can add a Kconfig option (opt in) to hit a website to increase a counter when a platform is being built. This is probably a terrible metric, but better than we have now. Hash the incoming IP address so that we only increment for one build a week from an individual. Yeah, it could be gamed, but meh, who cares. It just lets us know that the platform is still being built by someone. -- Add a script that again hits a website with information about what's running on a coreboot machine. Some data could be in the clear like platform name & build date. Other data could be hashed just so that we can get a rough idea of how many different machines are using an otherwise identical firmware. --- Please don't take any of these thought as me trying to argue with anyone. I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch. I just want to make sure that things actually aren't being used before moving them to a branch. Thanks everyone, and take care. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes
Apr 1, 2022, 05:43 by pe...@stuge.se: > Arthur Heymans wrote: > >> The context here, was that I voiced some practical concerns about >> >> using CBOR as a handoff structure. LinuxBIOS or coreboot tables were >> carefully designed to be very easy to parse. >> > > Your concern is valid and I think a key point. CBOR may not be bad > over a socket, but such a complex and arbitrarily extensible format > is much too error prone to be a good technical choice during boot. > > The same properties that make it technically unsuitable can of course > make it a perfect choice politically, for someone. > So if the idea is to create a payload handoff format that can be shared and used by multiple different firmware packages, do you have a better option? Yes, coreboot can just continue with just the coreboot tables, but that seems a little like sticking our head in the sand and refusing to recognize that other boot firmware exists. If there is going to be a new, "universal" handoff method, my thought is that it's better for us to participate in that and try to influence it to be as usable as possible. If we have a chance to replace HOBs with something better, what's the best we can get? If CBOR isn't better, what is? >> My objection to a new format like cbor was that it is likely very hard to >> parse using the same trampoline scheme. >> It is likely possible to write a trampoline using a stack in C, but then >> again that just complicates things a lot needlessly just to adopt a new >> format with probably little to gain. >> > > I see zero gain for coreboot. > > The gain is political for someone outside of coreboot; using a free > form and extensible data structure instead of coreboot tables moves > handover standardization out of the coreboot project and enables > arbitrary extension at will by someone not coreboot. > > I believe that would be a net loss for the firmware community at large. > Is there any suggestion for something better? We know that if Intel / UEFI want to update this, it's going to happen whether we want it or not. So how do we improve it? >> > * The coreboot project can, however, encapsulate a CBOR-based >> > handoff-structure into cbmem, similar to what we currently do >> > with ACPI tables. >> >> I think this is about supporting both a CBOR-based handoff and coreboot >> tables at the same time. >> My concerns here are that is requires some synchronization between both >> codepaths and just increases maintenance in general. >> Introducing multiple codepaths to do roughly the same is an error we get >> bit by way too often. I think we should be careful about this... >> > > Yes! Double trouble would be silly. If someone wants to use CBOR then > why not just create a payload for that, rather than trying to mess up > coreboot itself? > Sure, we can serialize this, make a translation layer for the cbtables to CBOR. It can be a coreboot option, or an intermediate payload. We decided that we didn't want to put all of the HOB creation code into coreboot itself, and we can do the same for whatever the next method is. If the FSP is going to use CBOR instead of UPDs, we'll already have the generation code in coreboot though, which isn't the case for the HOBs. We can currently read some HOBs, but to my knowledge, we don't generate any. > > >> > Additionally Intel was willing to look at using CBOR structures as >> > input and output to the FSP, so we could get rid of both the UPDs >> > & HOBs. >> >> This seems like the real positive upshot of that conversation! >> > > I agree that it could be a step forward, but I think the devil is in > the details. CBOR data structures can also be unneccessarily complex > and error prone, beyond the parser itself. > So maybe we try to limit the complexity? I'm not really familar with CBOR, so I don't know the issues with it. Intel did say that they were willing to look at other alternatives if we had any. If anyone has thoughts on alternatives, please suggest them. I hope nobody takes any of this as criticism - I appreciate the open discussion, and am sincerely looking for the best path forward here. Thanks, and take care. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: spkmodem output
I spoke with Phcoder (the original author) about this ages ago, and he recommended not actually playing sound with it, but using it with an audio cable between the output device and input device. I assume you'd be able to use it at a much higher speed that way. Martin Dec 7, 2021, 10:37 by nic.c3...@gmail.com: > On Tue, Dec 7, 2021 at 10:00 AM Peter Stuge wrote: > >> What if you build coreboot for emulation/qemu with spkmodem console? Does >> QEMU produce actual sound? I don't know whether QEMU has a speaker output. >> > > To add to this, QEMU will produce tones with the spkmodem console if > you add "-soundhw pcspk" to your qemu command line. I have tried it, > but spkmodem-recv was unable to decode the signal. I do recall being > able to get it working once on actual hardware by modifying the timing > in spkmodem.c such that the baud rate was some ridiculously low number > like 10 baud, and then messing with the #defines in spkmodem-recv, but > I don't remember what I set those defines to. > > Nicholas > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
If someone wanted to work with one of the approved coreboot contractors or individual contributor to set up a fundraiser of some sort to raise money to do things like this, that'd be great. We've had a requests for things like this in the past, but it's not something that the coreboot project itself can really do. We don't want to pit one group of coreboot developers against another, and the coreboot project also doesn't deliver binaries or sign contracts for work, so coreboot can't make guarantees about deliverables. I'd be happy to help get a fundraiser set up if anyone is interested in doing the work, but it's going to have to go through an actual fundraising site, and of course we'd want to have a full written plan before starting anything. Martin Nov 25, 2021, 18:03 by k.emery@internode.on.net: > I'm happy to contribute financially. It just comes with the caveat that I > need to know with some surety that I can finally have a working board at the > end of it. > > On a side note is there any kind of crowd sourcing platform / escrow service > for GPL projects? I know it's been talked about, and there have been attempts > made. But as far as I can tell, nothing has ever prospered. > > >> My ballpark estimation is a total of less than 100hours of >> contributors' time to migrate AGESA platform codes to avoid >> deprecation. Shared between five people who know what they are doing, >> it is very much doable within a month. >> >> Kind regards, >> Kyösti Mälkki >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hey Arthur, Nov 24, 2021, 05:50 by art...@aheymans.xyz: > Hi > I would like to suggest to deprecate some legacy codepaths inside the > coreboot tree and therefore make some newer ones mandatory. > ... snip ...> About the timeline of deprecations. Is deprecating non > conforming platforms from the master branch after the 4.16 release in 6 > months a reasonable proposal? > I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase. My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now. We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch. Would this schedule work? Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] 9 November 2021 - coreboot EFI working group meeting minutes
# 9 November 2021 - coreboot EFI working group Attendees: Martin Roth, Felix Held, Michael Niewöhner, Matt DeVillier, Nate DeSimone, Patrick Georgi, Tim Crawford, Werner Zeh ## Agenda: * [Edward] Supporting some UEFI interfaces continues to be a hot topic, one such area is ESRT table ASL generation within coreboot to better support platform firmware topology descriptions up the stack. quasisec@ is working on a proposal in the not so distant future. * [Patrick] It looks like the push to require linux to use EFI is coming from the “Universal” Scalable Firmware project. * [UniversalScalableFirmware/linuxpayload](https://github.com/UniversalScalableFirmware/linuxpayload) <https://github.com/UniversalScalableFirmware/linuxpayload](https://github.com/UniversalScalableFirmware/linuxpayload)> * [David] I think this has more to do with distros and OEMs expecting them for their manufacturing and testing purposes, for example [ubuntu-bios-uefi-requirements](https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf) <https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf](https://odm.ubuntu.com/docs/ubuntu-bios-uefi-requirements.pdf)> * 9.1. Legacy BIOS compatibility Ubuntu has been tested with UEFI-only mode BIOS and is also known to work with legacy BIOS compatibility mode (known as a Compatibility Support Module, or “CSM”) enabled. However, enabling legacy support will affect secure boot functionality, because it needs native-UEFI drivers and to be signed for validation during booting up * This looks like Intel trying to shape the future of firmware to suit their needs instead of coreboot's needs. * Are there any distros other than Ubunty looking at requiring UEFI? * [Nate] I believe these requirements are straight from Linux kernel. * [Patrick] In that case, they're probably an addition, not replacing the existing boot procedures. * Chip-agnostic loading would require this. * Someone from ARM proposing it. * [Nate] Linux is using EFI boot services to provide a more architecture agnostic Linux kernel launch [arch-agnostic initrd loading method for EFI systems](https://lore.kernel.org/linux-efi/20200207202637.ga3464...@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f) <https://lore.kernel.org/linux-efi/20200207202637.ga3464...@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f](https://lore.kernel.org/linux-efi/20200207202637.ga3464...@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f)> * What boot parameters are still actually used? Need to go through the kernel source to find out. (that’s what Patrick G did when building the linux trampoline in cbfstool) * Supports native X64 launch. * Matt could use additional reviewers on his patches. Initial patches were simple, but the later patches could definitely use more reviewers. The concern is that there are probably better ways to do these later patches. If they don’t get reviewed, they’ll be merged regardless so that we have a working branch, but it would be better if reviewed and reworked as needed. [edk2 project search](https://review.coreboot.org/q/project:edk2) <https://review.coreboot.org/q/project:edk2](https://review.coreboot.org/q/project:edk2)> * [Martin] Yabits tested, and as previously reported is not currently working. More testing and debug is needed. * Nate: It looks like there are a number of fundamental issues with yabits, so the U-Boot implementation might be a better choice as a 2nd implementation. There were rumors about that version being dead, or having been canceled, but it looks like patches are still being merged. * [Martin] Documentation about coreboot’s EFI plans is started and will be shared before the next meeting. * Jitsi performed very well compared to all of the other open source solutions that we’ve used. The only issue is a lack of call-in numbers. Patrick will look at setting up a server to test more. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Weird thoughts about blobs (was Re: Re: Another year, another blob?)
Nov 7, 2021, 04:13 by nic...@gmx.de: > On 07.11.21 00:11, Martin Roth wrote: > >> CB:55367 was pushed on June 9th. It's 5 months later. Intel hasn't been >> able to get it merged yet. Sure, we're not outright saying they can't get >> it in, but in effect, that's what's happening. >> > Yes, 5 months stalled, because nobody told them that we should discuss > it. Hence my proposal to discuss things early. You don't like it? Please > propose something better. > Okay, I'm removing the rest of this conversation now that you've agreed that you are actually talking about blocking platforms because of blobs. We both agree that we want things to be discussed. Let's start the conversation early, that's great. You want to block things until you're satisfied. I disagree. Blocking patches just makes companies work on a fork, and actually prevents the progress we all want. We both want coreboot to stay alive, and unfortunately, right now, that means that we're stuck dealing with blobs on the platforms that require them. If someone in a country that allows reverse engineering wants to work on replacing the blobs, that's great. Until then, they're the unfortunate reality. The advantage to putting things into the coreboot tree is that EVERYONE needs to work to not break other people's stuff with their changes. The coreboot community includes intel and AMD, and Google, and Secunet along with the people who don't work for any company. It's not any one individual's job, it's everyone's. If someone doesn't want to deal with the blobs, then just don't. You can't break those platforms, but you also don't have to work on them. Just don't use those platforms. As Ron said, "coreboot is best effort, not perfection." Let's try to work together on making things better Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Another year, another blob?
Nov 7, 2021, 04:29 by nic...@gmx.de: > On 07.11.21 00:15, Martin Roth wrote: > >> >> Nov 6, 2021, 05:49 by nic...@gmx.de: >> >>> It also seems that you underestimate the individuals in the >>> community. >>> >> I don't understand your statement that patrick is underestimating the >> individuals in the community. Are you saying that people would have worked >> around the blobs? If so, then why haven't we seen that code. We'd all love >> it. >> >> Could you explain? >> > > That's so easy to answer that I wonder if you are trolling me? > Nope. You say in a following email that if there's a question about what you mean, we should ask you, but then you wonder if I'm trolling you when I ask for an explanation? What's going on? > Long > story short, if a project is cluttered with blobs, you can't expect > people to go on as if that didn't happen. > Sure we can. It actually gives people something to start with and replace. > > When people are employed to work on blob support instead of native > implementations, they don't have the time to work on the latter. > Your scenario was "we'd started refusing blobs when the required blobs > started appearing". In such a reality, I assume less people would have > been employed to work on blob support. IIRC, there was a time when you > couldn't hire anyone for coreboot work because a certain blob supporter > already hired all of them. > I'm not sure who you're referring to as a blob supporter, but Google's never wanted blobs. Sage didn't either, they just needed anything to stay alive. The blob support has all been the chip vendors. And I think until Felix and Marshall went to AMD, the only other person involved in the coreboot community who went to a chip vendor directly was MrNuke when he went to intel. Everyone else has generally had to train people to work on coreboot. (Even Sage, with the exception of Marc Jones.) > Also, the upstream project became unfriendly towards solutions that > are not carried by the respective silicon vendor. I've witnessed that > first hand. For instance, when the first ramstage blobs were added, > the whole codebase for Intel silicon was kind of forked inside our > own repository, digging a deep ditch between the existing native code > and the support for newer platforms. In such an environment, it becomes > more unlikely that individuals add coreboot-native code. Somebody has > spent months to overcome that ditch btw. and IIRC that was to prepare > for some coreboot-native implementation that is already working. > I don't recall anyone being unfriendly towards solutions not done by the chip vendor. I agree that we haven't seen much, because of a lack of documentation and the difficulty in doing those ports. But could you point me to an example of a time when someone wanted to do a CPU/SOC port that coreboot refused because it wasn't done by the vendor? As far as I know everyone wants to move as much out of the blobs and back into coreboot as we can get. > There's also a general reluctance to expect to support a project with > free software that has shown that it doesn't take the GPL seriously. > Again, I'm not entirely certain what you mean here.I'm guessing you're talking about the "no linking" clause? We've talked to the lawyers at the SFC, and they haven't said that there's any issue with what's being done. Or are you saying that the SFC doesn't take the GPL seriously? Maybe there are differences of opinions on what taking the GPL seriously means? Are things that use BSD, MIT, or other non-copyleft licenses not to be taken seriously as free software? You ask to be taken literally, but I'm generally left being confused by your statements. I apologize. Feel free to respond if you want, but I think this is yet another place where we just won't agree. I definitely don't like the blobs, but I really don't see any world in which simply refusing them would have had a good outcome for the coreboot project. I'll leave this thread alone after this email. Regards, Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Another year, another blob?
Nov 6, 2021, 05:49 by nic...@gmx.de: > On 05.11.21 19:39, Patrick Georgi via coreboot wrote: > >> It [coreboot] would be dead: while there are still a few folks carefully >> maintaining >> i945 and GM45 in this reality, I'm not sure they would have done so in that >> other reality where there was no help maintaining the payloads (and so >> coreboot-compatible seabios, tianocore, grub, filo, ... would all be on >> their plate as well) >> > > That seems an odd assessment. Did you confuse blobs that are "required" > in coreboot with blobs that sit in the same storage medium (e.g. ME > firmware)? It also seems that you underestimate the individuals in the > community. > I don't understand your statement that Patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it. Could you explain? Thanks. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Another year, another blob?
Nov 6, 2021, 05:49 by nic...@gmx.de: > On 05.11.21 19:39, Patrick Georgi via coreboot wrote: > >> It [coreboot] would be dead: while there are still a few folks carefully >> maintaining >> i945 and GM45 in this reality, I'm not sure they would have done so in that >> other reality where there was no help maintaining the payloads (and so >> coreboot-compatible seabios, tianocore, grub, filo, ... would all be on >> their plate as well) >> > That seems an odd assessment. Did you confuse blobs that are "required" > in coreboot with blobs that sit in the same storage medium (e.g. ME > firmware)? It also seems that you underestimate the individuals in the > community. > I don't understand your statement that patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it. Could you explain? Thanks. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Weird thoughts about blobs (was Re: Re: Another year, another blob?)
Nov 6, 2021, 05:21 by nic...@gmx.de: > On 05.11.21 18:15, Martin Roth via coreboot wrote: > >> Nov 4, 2021, 05:24 by pmen...@molgen.mpg.de: >> >>> On 20.10.21 14:24, Nico Huber wrote: >>> >>>> My proposal: >>>> How about we set up some guidelines how to proceed when adding support >>>> for a new platform that requires any blobs? My vague idea is as follows: >>>> Before the very first commit for such a new platform can be merged, a >>>> set of predefined, blob related questions (to be discussed) should be >>>> answered. This should also apply if a new platform just brings the same >>>> kind of blobs with it as its predecessor (e.g. next gen FSP). Situations >>>> may change and blobs do too. Speaking of FSP, it's actually a set of >>>> many blobs. I think questions should be answered for each part of it >>>> individually. >>>> ...>> What do you think? >>>> >>> >>> Thank you for bringing this up, and I totally agree. Reaching out to the >>> coreboot community and including it in the planing phase is currently >>> lacking quite a lot. The coreboot mailing list is the perfect forum for >>> that, but unfortunately not used a lot.>> >>> Kind regards, >>> Paul >>> >> The current reality is that binary blobs are needed for almost every >> platform in coreboot. I believe the coreboot leadership is united behind >> the unfortunate reality that allowing these blobs is a requirement for the >> platform. >> > > Not sure what you are trying to say. Do you mean we shouldn't talk about > the way blobs are added because they are needed anyway? Blobs are needed > anyway so we won't review code around them any more? > Not at all, you can talk all you want. But what's the outcome you're looking for? Do it the coreboot way, or or what? Or we won't accept code to load those blobs? You won't accept ANY of the code for the platform? Is there a different end point if they don't do what you want? To me, your statement below *VERY* much sounds like refusing a platform. Maybe you could explain what it actually means. I read it as "A vendor can't commit a new platform until the coreboot project is happy with the blob situation for the platform". ``` Oct 20, 2021, 06:24 by nic...@gmx.de: My vague idea is as follows: Before the very first commit for such a new platform can be merged, a set of predefined, blob related questions (to be discussed) should be answered. ``` >> I don't think we're going to refuse a platform right now simply because it >> has blobs. >> > Nobody brought that up. What are you referring to? > See your above statement. If you'd said "at the start of a new project, we'd like to get the vendor to let us know what the blob situation looks like", sure. But the way it was phrased of "Before the first commit can be merged" says to me that you don't want to allow the platform to even get started in coreboot until you (or someone) is satisfied by the blob situation for the new platform. It's not like that discussion is going to be quick either. Blobs are ALWAYS contentious, which I'm fine with. I'm just not fine with blocking the progress of people who are trying to do their best to get their work done simply because we don't like blobs. >> I'm not sure what coreboot would look like right now if we'd started >> refusing blobs when the required blobs started appearing, but it definitely >> wouldn't have many modern platforms. >> > > That's a very hypothetical, IMO wrong statement. "definitely" is a very > strong word there. Also, what's a "required blob" anyway? Most of the > blobs in coreboot are not required but politically desired. As an ex- > perienced coreboot developer who has written fully open-source platform > support in the past, I would expect this to have happened: We'd have > less ARM platforms in the tree because those were added for Chromebooks > with little interest from other folks. On the x86 end, we'd be behind > about a year compared to the support we have today, as other companies > who rely less on the silicon vendor's blessing might have done the job. > The community would look much different. Instead of many developers > struggling to bring blobs up, we'd have less but much better experienced > developers who still understand the hardware. > > Of course we'll never know which scenario would have been more likely. > But it's been almost ten years, a lot could have happened. Imagine > coreboot would have been FSP free, maybe even AMD would have been more > open to a free software solution. FWIW, FSP
[coreboot] Re: Providing an Interface to load PSE FW for Intel Elkhart Lake Platform
Nov 5, 2021, 14:10 by nic...@gmx.de: > On 05.11.21 18:58, Martin Roth wrote: > >> This binary is also mandatory for the elkhart lake platform, so to support >> this platform, loading this is required, whether it's built from source as a >> part of the coreboot build or supplied as a blob. >> > That's not true. Just rumors? > This is what was reported by the intel representative in the leadership meeting. I can't say whether it's true or not, this is however what was reported. If it's optional though, then why do you even care, just don't use it and default it to off. If other people want to be able to use it, why are you concerned about preventing them? >> The decision at the leadership meeting was to allow this binary to be loaded >> by coreboot, so long as the PSE acts like an EC, and does not have access to >> the X86 memory space. >> > The discussion happened under a false pretext and with outdated > information. Also, the PSE is nothing like an EC. Hint: does an > EC do parts of the SoC silicon init that would usually be done > by our ramstage? > Then you shouldn't be worried. It was decided to accept it *so long as the PSE acts like an EC* as i said above. If that's not actually the case, then Sheng won't be able to show that it acts like an EC and there's no issue. Though if it's actually optional, again, what's the issue? What is it that it does that's normally done by coreboot's ramstage? > Maybe to avoid wasting time with premature decisions, we should > make up some guidelines? For instance, first discuss something on > the mailing list, then in the leadership meeting? This way people > could at least get a little information before they make decisions. > There are lots of options here: - There's an agenda that's posted before the meeting. Other things do come up in the meeting, but this item had been posted for at least a week before the leadership meeting, so there was plenty of time to look at it and decide whether or not to come. - People who believe they have information to share or want their opinions heard can come to the leadership meeting. If they aren't there, they don't get to voice an opinion in the meeting. - People can respond to the meeting minutes when they're posted to the mailing list or look at the minutes in the document. Ultimately, the decision about the direction that the coreboot project is going to go is decided by the coreboot leaders, currently Stefan, Werner, and David. Sure, discussions can happen on the mailing list, but the leadership meeting is where the decisions get made. I've added your suggestion about requiring discussions on the mailing list to the meeting minutes of the next meeting. If you'd like to discuss the idea in the meeting, please attend. >> The load method wasn't discussed beyond what's in CB:55367, so if there's a >> different load method that's desired, that could be acceptable, but I think >> we can close the discussion on whether or not to allow the binary loader to >> be added, provided Sheng can show that this part doesn't have security >> implications for the X86 side. >> > > Interesting point about the security. I'm also curious. I couldn't > find anything about the mentioned MMU in Intel's docs. > > Nico > > PS. Please have a look at the available documentation before making > decisions. > And again, the decision was made conditionally upon the information we were given. If you want to voice concerns, please come to the meetings. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] 03 November 2021 - coreboot Leadership meeting minutes
# 03 November 2021 - coreboot Leadership meeting minutes Edited for clarity and formatting. * Attendees: Christian Walter, David Hendricks, Felix Held, Felix Singer, Jason Glenesk, Jay Talbott, Martin Roth, Matt DeVillier, Patrick Georgi, Piotr Król, Ron Minnich, Sean Rhodes, Stefan Reinauer, Tim Crawford, Werner Zeh ## Ongoing Items * New videoconferencing system? The desire for a new way of having meeting is because the current Google Meet platform requires a Google Employee to allow access. It would also be nice to use an open platform instead of a proprietary one, but we need something stable that we can all access. * BigBlueButton was used for the last coreboot EFI working group meeting and worked relatively well for most people, though some still seemed to have issues. * Matt - BBB did a poor job of filtering background noise. Not as good from an audio perspective. * Felix - same. Audio is much better in meet. * We probably do not want to use BBB at this time. * Should we try Jitsi? Limits: 100 ppl is free limit * [https://meet.jit.si/](https://meet.jit.si/) * Does this work with firefox? It used to have issues with some browsers. * We'll test this for the next EFI working group meeting * So far Google Meet seems to offer the best quality. * Can we use the Public version of google Meet? * 1 hour limit? * Number of people? * Can coreboot make an Google workspace account and host the meetings with Google Meet? * Yes, it has a free tier for non-profits. We'd need to work this out with SFC as they're the actual non-profit. ## Agenda: ### [martin] Trademark issues with starlabs. * StarLabs used the coreboot name in a way that creates confusion. * What would a reasonable release name be? * Starboot * Add "Star Labs" prefix before "coreboot" to make clear that it's a distro * coreboot version 4.15-company-7 (recommended naming scheme when not doing their own distro like libreboot, pureboot, ...) * We should document acceptable use and naming of the coreboot trademark. * Should coreboot go back to quarterly releases? * [Sean (Star Labs)] Yes, this would help. ### [Martin] 2022 coreboot (only) conference/hackathon/summit It’s been several years since we had a coreboot summit, and the thought is that this would be mostly focused on hacking and discussing improvements to the project instead of having a significant number of talks. * [Chris] Do we need another in person event? OSFF is willing to plan/take over costs * [Martin]Yes, after looking at the agenda for the latest OSFC, it was felt that a coreboot-only conference might be useful. If OSFF wants to pay for it, that’d be great, but I don’t think that OSFF should replace coreboot. * [Werner] Sounds like a good plan * [David] Choose a place with fewer restrictions (needs to be predictable). * In April after OCP regional summit - OSFF Meetup with hackathon ~40 ppl * [Ron] 4-day thing in Prague already planned for the week after OCP. April 21-24. Do this in parallel with the OSFF meeting. * Martin, Ron, and Chris will meet soon to discuss expanding this meeting. * [Chris] OSFC 2022 will be (hopefully) in south korea ### [Martin] Use of pseudonyms at coreboot. We currently require the use of real names at coreboot for legal reasons. This bothers some people. Could we introduce a method to allow reasonable pseudonyms by having a verified name held privately to associate with the name used in gerrit? I’d rather not have everyone switch and end up with code checked in as booty-mcbootface, but it seems reasonable to protect people’s privacy if desired. * [Werner] Is there a trust for source code? Basically a broker who submits the patches for people. * This is suggesting “Code laundering”. * Things like this are just being established now, but maybe shouldn't be allowed. * The entity submitting code would be responsible for this (this is supported by the [Developer’s Certificate of Origin](https://coreboot.org/Development_Guidelines#Sign-off_Procedure), part (b) or (c)) * [Martin] Can we have a company audit the code? Then it wouldn't matter as much if someone anonymously submitted code because troublesome code could be caught. * The coreboot server is in Germany, so the codebase is following their laws. * It might be best not to have a policy because then if there are issues, lawyers could actually come after us for the policy not being sufficient. * What does Linux do? * They have the linux foundation and with ~70% (estimate drawn from thin air) of big IT corporations being members, they play by different rules. * What do other projects do? * Let’s ask the SFC. * The important thing is to make sure that we’re making an effort to keep questionable content out. ### U - Usable & Effective Firmware Initiative. Created to create standards that coreboot can use. This origina
[coreboot] Re: Providing an Interface to load PSE FW for Intel Elkhart Lake Platform
Oct 31, 2021, 15:03 by nic...@gmx.de: > Hi Sheng, > > On 27.10.21 06:29, Tan, Lean Sheng wrote: > >> As mentioned earlier the Firmware of the PSE needs to be loaded at boot time >> of the host CPU, this is mandatory for Elkhart Lake. >> > ... > > so as far as I understand it this is not necessarily a blob, your patch > only treats it like one? Or is there any need to make it proprietary? > > ... > > OTOH, if we'd add an option to load an external file like your patch > suggests, we'd lose a lot. Not only, would it complicate the build > process, we'd also have another platform that can't boot without > external files. And that is more error-prone and always leads to more > support requests, frustration etc. It's bad for the project, IMHO. > > Nico > > The issue of loading the PSE firmware was brought up in the coreboot leadership meeting on October 20. Sheng mentioned that the desire/plan is to open the code for the PSE binary at some point, but it isn't open yet. This binary is also mandatory for the elkhart lake platform, so to support this platform, loading this is required, whether it's built from source as a part of the coreboot build or supplied as a blob. The decision at the leadership meeting was to allow this binary to be loaded by coreboot, so long as the PSE acts like an EC, and does not have access to the X86 memory space. The load method wasn't discussed beyond what's in CB:55367, so if there's a different load method that's desired, that could be acceptable, but I think we can close the discussion on whether or not to allow the binary loader to be added, provided Sheng can show that this part doesn't have security implications for the X86 side. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Another year, another blob?
Nov 4, 2021, 05:24 by pmen...@molgen.mpg.de: > On 20.10.21 14:24, Nico Huber wrote: > >> My proposal: >> How about we set up some guidelines how to proceed when adding support >> for a new platform that requires any blobs? My vague idea is as follows: >> Before the very first commit for such a new platform can be merged, a >> set of predefined, blob related questions (to be discussed) should be >> answered. This should also apply if a new platform just brings the same >> kind of blobs with it as its predecessor (e.g. next gen FSP). Situations >> may change and blobs do too. Speaking of FSP, it's actually a set of >> many blobs. I think questions should be answered for each part of it >> individually. >> ...>> What do you think? >> > > Thank you for bringing this up, and I totally agree. Reaching out to the > coreboot community and including it in the planing phase is currently lacking > quite a lot. The coreboot mailing list is the perfect forum for that, but > unfortunately not used a lot. > > Kind regards, > Paul > The current reality is that binary blobs are needed for almost every platform in coreboot. I believe the coreboot leadership is united behind the unfortunate reality that allowing these blobs is a requirement for the platform. I don't think we're going to refuse a platform right now simply because it has blobs. I'm not sure what coreboot would look like right now if we'd started refusing blobs when the required blobs started appearing, but it definitely wouldn't have many modern platforms. We all agree that we don't like adding more proprietary binaries, but there are times when a binary needs to be closed for a time until the platform is released such as with the PSE. This should be acceptable, so long as the promise is actually followed through upon. If not, the company making that promise loses credibility. Unfortunately, that's not always a great motivator. Maybe the coreboot organization & SFC can enter into a contract that specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee. Every company is in business to make money in some way. If there's no profit to be made doing something, they're going to have a hard time keeping their doors open. So long as they don't see a financial benefit to being open-source, they're simply not going to do it. To make this happen, we need more companies requesting that the chip vendors open their proprietary blobs. Being more involved in the planning phase would be great, and obviously there are companies contributing to coreboot who ARE involved in these discussions. Expecting companies to discuss their plans for future chips in the open probably isn't going to happen. Simply refusing to accept the binaries *only hurts us*, most companies will be probably happy using Slimboot or TianoCore. Making things difficult to work with coreboot only makes it easier to show why something shouldn't be open and why the chip vendors shouldn't work with coreboot. I cant tell you how many times I've heard that the reason coreboot wasn't used or wasn't upstreamed was that it takes too long to get changes into coreboot. These things said, I think we can come up with solutions to make things easier. Ron suggested several years ago that we could enable Kconfig to only show the platforms with the amount of binaries that people are comfortable with. Maybe we need to look into that more. We can require that the soc/cpu/chipset Kconfig screens display what blobs are required. We can push to get anything we can moved from the blobs into coreboot. We can, and we are, pushing the vendors to be more open-source friendly, and we're finally starting to see some more and more people at these companies buying into this. Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] 20 October 2021 coreboot Leadership meeting minutes
# 20 October 2021 - coreboot Leadership ##Attendees: Felix Singer, David Hendricks, Arthur, Werner, Piotr, Lean Sheng Tan, Marshall, Jason Glenesk, Jay Talbott, Matt DeVillier, Patrick Georgi, Tim Crawford, Martin, Stefan, Felix Held ## Agenda: * [patrick g] “Verified+1” permissions on gerrit repos that aren’t build tested (e.g. homepage.git): open up? For which groups? * For which repos? * Blobs - Only people appointed by Stefan for legal reasons. * Homepage: All submitters? Owner’s +2 or verified doesn’t count. * [martin] Clean up the coreboot root folder? * /spd, /gnat.adc, /Makefile.inc, /toolchain.inc -> src * Move spd directory to src/lib (or src/device?) * Look at moving gnat.adc to /src. Might be difficult to move * Move toolchain.inc to /src - only included by top level makefile * (keep Makefile.inc in place, otherwise it has to refer to ../util which is ugly) * /configs -> util/abuild * Having this here may help with visibility of platforms * Leave this here, remove subdirectory * /MAINTAINERS, /AUTHORS -> Documentation * Leave both of these at the top level * MAINTAINERS is machine readable and not really “Documentation”, AUTHORS is a “standard file” * Remove COPYING - it’s a copy of the GPL V2 license, which we have under /LICENSES * Leave this here: standard location so license checking and compliance tools are happier to find it there. * Update README.MD to point into /Documentation and each .md in other directories. * Marshall will do this. Thanks! * Add a .mailmap file [to correctly map authors to an email address](https://git-scm.com/docs/gitmailmap). * Yes * Should we lock it to the result after moving anything so that additional objects can’t be created without deliberation? * Add a lint test to keep other files from being added without discussion. * [Martin] When do we need another coreboot EFI working group meeting? * Next tuesday - send out invites after this meeting. * Lots of issues joining last time. * [Werner] Discuss patch [CB:55367](https://review.coreboot.org/c/coreboot/+/55367) regarding Intel PSE (Programmable Service Engine) * Must be loaded at boot time by a piece of firmware. * Discussed osfc2020 - zephyr based, but not open yet. * Patch just adds the loading from cbfs so that FSP can load it. * Yet another blob without notifications. * Blob is unfortunately mandatory for the platform. * Initializes the ARM processor then stops running? * It may be possible to write an open version? * The process of open sourcing the code for this takes a long time, so this is (in theory) a temporary solution. * The processor is EC-like, handles realtime interface, has I2C interface. * PCIe devices can be assigned to either the device or X86. * Sheng and Werner will verify that this is more similar to an EC than the ME. * If this is EC-like, this shouldn’t be an issue. * [Arthur] Logging: (optional) printing the error level in front of the message? * Would need to have a little logic to allow a line to continue without printing again. * Loglevel in brackets. * Sure, let's try this - so long as it's optional, there's not much of a downside. * [Martin] Adding requirements for blobs in coreboot’s repos * Nico [suggested requesting/requiring some additional items for blobs](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/AV5LYYLMMFWYIR5R2OW6A2M7XGI2SBHX/). * We already have[ a list of requirements](https://review.coreboot.org/plugins/gitiles/blobs/+/refs/heads/master/README.md), so updating that doesn’t seem unreasonable. * How do we want to handle non-coreboot-owned blob repos - fsp/intel_microcode/amd_blobs/qc_blobs/ * Let’s review the blobs directory and see what’s still needed. * Revisit next meeting ## Mailing list discussions of interest: * Mailing list question about [arm64 ports of coreboot](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/TOWWCZL6XUKIPQO5SRX4JRHEPO3SI2XJ/) * Mailing list: [firmware and bootloader log spec](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/OUGJENEVQAVL7AA2YIIHAW6BQNNSALGQ/) * (LPC 2021 System Boot and Security MC discussion about that)[https://youtu.be/JwU1_hyOzMI?t=4329] ## Ongoing items: * [New videoconferencing system?](#bookmark=id.ehzxgz9a1ta0) * Big Blue Button (maintained install: senfcall.de, [coreboot room](https://lecture.senfcall.de/pat-yut-ayj-bc6) set up by pgeorgi) * At the end of the meeting, please try to join the coreboot room here, so we can see if it’s working for people. * What happens if the host doesn’t join - seems fine. * This was tested by a number of people after the meeting, and it seems better than bluejeans. There weren't any reports of people not b
[coreboot] Re: Another year, another blob?
Accidentally responded off the mailing list initally. :-/ Oct 20, 2021, 08:07 by matt.devill...@gmail.com: > On Wed, Oct 20, 2021 at 8:53 AM Andy Pont wrote: > >> >> Nico wrote... >> >> How about we set up some guidelines how to proceed when adding support >> >> for a new platform that requires any blobs? My vague idea is as follows: >> ... >> We already have a list of things required to go in with binaries checked into the blobs repo. I personally don't have any objection with updating the document if more things are needed. https://review.coreboot.org/plugins/gitiles/blobs/+/refs/heads/master/README.md We could also add a jenkins build that helps to verify that these are met - at least check that any commit of a binary updates the release notes. Maybe use a machine-parsable template similar to board_info in the coreboot mainboards directory. This could contain all of the information required. >> Taking EC firmware as an example, in many situations the short answer is >> “it resides in the same binary image as coreboot and is a blob because >> that is all there is”. Based on your list of questions I’m not >> convinced that would be sufficient to get it merged. >> > > Why would we be adding EC blobs to the coreboot repo? > I'm assuming we're talking about the coreboot blobs repo, not the actual coreboot repo. The EC firmware sometimes runs out of the boot rom, so the final firmware must also contain the EC image. I realize that it's a point of contention in the coreboot community whether the coreboot build process should produce a complete binary. Some feel that it's more appropriate for users to add any external bits outside of the coreboot build. If we're going to allow binaries into the coreboot build process though, I don't see a reason to exclude EC binaries. If any EC images were added, they'd need to be licensed as being redistributable before they could be added. They can't just be pulled out of someone else's image and hosted in the coreboot blobs repo. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
