[coreboot] Gerrit Gitiles is back - for now

[Felix Singer]

I've just enabled Gitiles again.

We will observe which effect this has on Gerrit now. Fingers crossing
that it won't cause a high load anymore :)


Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Maintenance/downtime for review.coreboot.org

[Felix Singer]

I've successfully finished the migration and also updated Gerrit to
version 3.10. The version bump brings quite a lot new things :)

It took longer than expected, unfortunately, even with an extra long
maintenance time.

However, as always, if you experience any issues then please let us
know using one of the community forums.


Have fun and Happy hacking!

Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Maintenance/downtime for review.coreboot.org

[Felix Singer]

We are going to move Gerrit to a different server, which requires a
downtime for a couple of hours.

The maintenance is scheduled for

  today, 2024-05-18 9:00 AM UTC+0

*** Please DO NOT try using Gerrit from this time on ***

The maintenance is expected to take ~4 hours. I'm trying to keep the
downtime as little as possible.

Since with the movement the IP address changes as well, it might take
some time until Gerrit is reachable for you again. This depends on how
frequent the DNS server you are using gets updated.

If you run into connection problems, please make sure to clear/update
your local DNS cache. Alternatively, you can add the following mappings
to your local hosts file until your DNS server gets the update.

  213.133.110.228 review.coreboot.org
  2a01:4f8:222:1649:c02e:b007:0:1 review.coreboot.org

If you still encounter problems, then please reach out over the mailing
list.


Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: qa.coreboot.org will be down for ~1 hour

[Felix Singer]

It took a little bit longer than expected. I shouldn't have planned too
tight :)

Anyway, Jenkins was just moved to another server. I'm going to give
some more details in a dedicated mail.

Please, as always, let us know if you notice any problems.


Happy hacking!

Felix

On Mon, 2024-05-13 at 01:06 +, Felix Singer wrote:
> We are going to move Jenkins on another server. So the CI will be
> offline for a bit.
> 
> This does not have an effect on Gerrit. So Gerrit stays working as
> usual.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] qa.coreboot.org will be down for ~1 hour

[Felix Singer]

We are going to move Jenkins on another server. So the CI will be
offline for a bit.

This does not have an effect on Gerrit. So Gerrit stays working as
usual.


Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #536] Cannot build coreboot-sdk

[Felix Singer]

Issue #536 has been updated by Felix Singer.


Michał Żygowski wrote in #note-4:
> Patch: https://review.coreboot.org/c/coreboot/+/82066
> 
> Couldn't build coreboot-sdk completely, because gerrit is having some 
> troubles (getting 504 when cloning or accessing it via browser)

I've retriggered the build task. Seems like Gerrit had a hiccup.


Bug #536: Cannot build coreboot-sdk
https://ticket.coreboot.org/issues/536#change-1814

* 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] [coreboot - Bug #536] Cannot build coreboot-sdk

[Felix Singer]

Issue #536 has been updated by Felix Singer.


I don't know, but I rebuilt the containers with testing instead of Sid weeks 
ago when the xz drama happened. I pushed new containers for last stable release 
and current main branch to Dockerhub.


Bug #536: Cannot build coreboot-sdk
https://ticket.coreboot.org/issues/536#change-1809

* 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: I can't build crossgcc

[Felix Singer]

Hi Keith,

did you check if your crossgcc directory is dirty? Is there an existing
xgcc directory?


Felix


On Mon, 2024-02-19 at 15:08 -0500, Keith Hui wrote:
> Hi guys,
> 
> I was unable to build crossgcc. The important tail end of build log
> is
> included at the end.
> 
> I couldn't figure out why. There should be no binutils-2.33.1
> anywhere
> on my system. The build script is pulling in 2.41, and my host
> binutils is 2.40.
> 
> Appreciate any help.
> Thanks
> Keith
> 
> ---8<---
> 
> make[2]: Entering directory
> '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS/zlib'
> make[2]: *** No rule to make target
> '../../binutils-2.33.1/zlib/adler32.c', needed by 'libz_a-adler32.o'.
> Stop.
> make[2]: Leaving directory
> '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS/zlib'
> make[1]: *** [Makefile:10810: all-zlib] Error 2
> make[1]: Leaving directory
> '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS'
> make: *** [Makefile:1004: all] Error 2
> make[1]: Entering directory
> '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS'
> /bin/sh ../binutils-2.41/mkinstalldirs
> /usr/src/coreboot/util/crossgcc/xgcc
> /usr/src/coreboot/util/crossgcc/xgcc
> /bin/sh: line 4: cd: ./libsframe: No such file or directory
> make[1]: *** [Makefile:12900: install-libsframe] Error 1
> make[1]: Leaving directory
> '/usr/src/coreboot/util/crossgcc/build-x86_64-elf-BINUTILS'
> make: *** [Makefile:2580: install] Error 2
> ___
> 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 24.02 release tag on next Monday!

[Felix Singer]

The next coreboot release tag is scheduled for next Monday, February
19th!

With the upcoming release we are changing our release number format
from a version number to a date format. So it will be versioned 24.02.

As always, please test any mainboards, give feedback, and if possible
submit a patch for review if you found an issue. We appreciate any
help.

Also, let us know if there are any patches which need to make it into
the release. You can do that by responding to this email and by adding
the following hashtag to the related patch on Gerrit. The hashtag field
is shown after clicking on the "show all" button from the top left
information block of a patch.

coreboot_release_2402 [1]

We are using another hashtag in order to track patches which are
important or useful in some way, maybe even ready to be submitted, but
might break something and thus the risk is too high right before the
release. So we prefer to submit them after the release which gives
enough time for testing until the next release. Examples are version
updates to the toolchain or updates to the FSP submodule pointer.

The hashtag is as follows:

coreboot_post_release_2402 [2]

Please don't hesitate and reach out to us if you have any question.


Felix
---
[1] https://review.coreboot.org/q/hashtag:coreboot_release_2402
[2] https://review.coreboot.org/q/hashtag:coreboot_post_release_2402
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Build server maintenance on Saturday, Dec 2

[Felix Singer]

Server maintenance finished. All build servers are back up again.


On Sat, 2023-12-02 at 13:16 +, Felix Singer wrote:
> Finished the planned maintenance on the builders Bob, Muck, Pickles
> and Pilchard. They are back online.
> 
> Since there doesn't seem to be much traffic on Gerrit today, and
> while on it, I'm going to take the builders Roley and Scoop for
> another maintenance offline as well.
> 
> 
> On Sat, 2023-12-02 at 10:58 +, Felix Singer wrote:
> > The maintenance starts now.
> > 
> > 
> > On Fri, 2023-12-01 at 08:43 +, Felix Singer wrote:
> > > I will do a maintenance on some build servers this Saturday, Dec
> > > 2. You might experience long waiting times for builds.
> > > 
> > > The maintenance is scheduled for 12pm UTC+1 and it's expected to
> > > be finished at 4pm UTC+1.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Build server maintenance on Saturday, Dec 2

[Felix Singer]

Finished the planned maintenance on the builders Bob, Muck, Pickles and
Pilchard. They are back online.

Since there doesn't seem to be much traffic on Gerrit today, and while
on it, I'm going to take the builders Roley and Scoop for another
maintenance offline as well.


On Sat, 2023-12-02 at 10:58 +, Felix Singer wrote:
> The maintenance starts now.
> 
> 
> On Fri, 2023-12-01 at 08:43 +, Felix Singer wrote:
> > I will do a maintenance on some build servers this Saturday, Dec 2.
> > You might experience long waiting times for builds.
> > 
> > The maintenance is scheduled for 12pm UTC+1 and it's expected to be
> > finished at 4pm UTC+1.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Build server maintenance on Saturday, Dec 2

[Felix Singer]

The maintenance starts now.


On Fri, 2023-12-01 at 08:43 +, Felix Singer wrote:
> I will do a maintenance on some build servers this Saturday, Dec 2.
> You might experience long waiting times for builds.
> 
> The maintenance is scheduled for 12pm UTC+1 and it's expected to be
> finished at 4pm UTC+1.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Build server maintenance on Saturday, Dec 2

[Felix Singer]

I will do a maintenance on some build servers this Saturday, Dec 2. You
might experience long waiting times for builds.

The maintenance is scheduled for 12pm UTC+1 and it's expected to be
finished at 4pm UTC+1.


Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot has switched the default git branch from "master" to "main"

[Felix Singer]

Hi Martin,

On Sat, 2023-09-09 at 18:20 -0600, coreboot org wrote:
> The master branch will no longer accept pushes.

it seems people are still able to use refs/for/master. Some patches
were just pushed for master today, but they are already rebased to the
main branch now. Can we prevent that or can we only prevent submissions
to the master branch?


Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Patches moved to main branch lost review scores

[Felix Singer]

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,
> . 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] Re: disable efficient-cores or performance-cores in Intel 12th gen processors

[Felix Singer]

Yeah, I think too. I will start with the pre-release process for
coreboot 4.21 next week. I will finish this then :)


Felix


On Sat, 2023-06-24 at 18:15 +0200, baptx wrote:
> Hello, thanks for your contribution.
> Is there any chance to have the option to disable efficient or
> performance cores in the next firmware, for example on NovaCustom
> NV41 laptop? 
> I also saw another way to disable efficient or performance cores
> without needing to reboot, using taskset but I did not try it yet:
> https://unix.stackexchange.com/questions/686459/disable-intel-alder-lake-efficiency-cores-on-linux
> The option in the BIOS could still be useful to have a default
> configuration.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: id.coreboot.org Keycloak server problems

[Felix Singer]

Hi Carl-Daniel,

I guess the Keycloak is not really maintained. It was more a try or
experiment.


Felix

On Wed, 2023-06-21 at 00:31 +0200, Carl-Daniel Hailfinger wrote:
> I just tried to log in to Gerrit with the link "Keycloak OAuth2
> (gerrit-oauth-provider plugin)
> <
> https://review.coreboot.org/login/%2Fc%2Fflashrom%2F%2B%2F50264?id=ger
> rit-oauth-provider_-keycloak-oauth>",
> but the redirect to https://id.coreboot.org/... gets stuck during TLS
> negotiation. Firefox says PR_END_OF_FILE_ERROR.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: GSoC 2023-Provide Toolchain Binaries

[Felix Singer]

Hi Komal,

Welcome and thanks for your interest in coreboot :)

Mentors will be assigned later to the people and projects, when we have
all applications.

However, as listed on our GSoC page, you can find all important
information here https://doc.coreboot.org/contributing/gsoc.html


Felix

On Sat, 2023-03-25 at 12:24 +0530, Komal S wrote:
> This is Komal Sambhus from Mumbai, India. I had earlier expressed my
> interest for the project 'Provide Toolchain Binaries'. It would be
> great to get in touch with the mentors for this project to proceed
> further.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: disable efficient-cores or performance-cores in Intel 12th gen processors

[Felix Singer]

Hi everybody,

I have created a patch which adds Kconfig and runtime options for both
of these settings.

https://review.coreboot.org/c/coreboot/+/73790

Let me know your opinion.


Felix

On Thu, 2023-03-02 at 11:27 +0100, Michał Żygowski wrote:
> On 1.03.2023 18:58, baptx wrote:
> > For people who use the 12th generation of Intel Core processors,
> > they may want
> > to disable efficient-cores in the BIOS to improve performance
> > (
> > https://www.reddit.com/r/intel/comments/thp7jh/disabling_the_efficie
> > ncy_cores_to_get_performance/ <
> > https://www.reddit.com/r/intel/comments/thp7jh/disabling_the_effici
> > ency_cores_to_get_performance/>), is it supported by coreboot or
> > Dasharo?
> > 
> > Some people may also want to disable performance-cores instead to
> > save more
> > battery
> > (
> > https://www.reddit.com/r/overclocking/comments/x0xu1c/can_you_disabl
> > e_performance_cores_to_force_an/ <
> > https://www.reddit.com/r/overclocking/comments/x0xu1c/can_you_disab
> > le_performance_cores_to_force_an/>), is it supported also?
> > 
> Intel FSP, which is used to initialize the Intel silicon in coreboot
> is capable
> of disabling E and P cores. It is a matter of telling FSP to do it.
> But I assume
> you expect a runtime option in the firmware setup, so the answer is
> no, neither
> Dasharo nor coreboot supports it at the moment. Currently, the only
> way to
> achieve it is a custom coreboot build.

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] 4.20 release preparations

[Felix Singer]

Hi everyone,

2 months passed since last release and the 4.20 release is ahead of us.

I'm starting with the release preparations on Monday, which means I'm
going through the patches on Gerrit (also the merged ones) and see what
could add some value to the release and what needs more documentation.

Patches, which should be included in the release, are marked with the
following hashtag:

   coreboot_release_4.20

Patches lacking of documentation (no matter if release notes, user or
developer documentation), are marked with the following hashtag:

   coreboot_needs_documentation

Hashtags can be added by everyone, but the field for that is a little
bit hidden. Once you have a patch open, click on "Show all" in the top
left corner and then the hashtag field shows up in the list.

Please feel free to add any of these hashtags yourself. In addition to
that, add at least me to the reviewer list so that I'm getting notified
and aware of it.

If you add the hashtag for missing documentation, also add a comment
about what exactly is missing.

I will try to summarize the status at the end of each week.


Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Refactoring #460] Make mainboards using the variant concept

[Felix Singer]

Issue #460 has been updated by Felix Singer.

Description updated


Refactoring #460: Make mainboards using the variant concept
https://ticket.coreboot.org/issues/460#change-1441

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-02-14

* asrock/ivybridge
  * asrock/b75pro3-m
  * asrock/h77pro4-m



-- 
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 participates in GSoC '23

[Felix Singer]

Hello coreboot fellows,

coreboot has been accepted to Google Summer of Code 2023 [1]!

We officially would like to encourage interested GSoC students to talk
to us and discuss possible projects. This could be one of our existing
ideas or a new idea you have on your mind. You can find a list of our
community forums in our documentation [2]. 

We prepared a list of projects [3] and we started brainstorming on more
project ideas [4]. No matter whether you want to participate as a GSoC
student or mentor, if you are interested in anything or if you want to
share an idea then please let us know. Don't hesitate talking to us :)

So, what's next? Let's have a look at the timeline [5]: 

  * Discussing possible projects (February 22th - March 19th)

  * Submitting your application (March 20th - April 4th)

Please read our GSoC guide [6]. It explains our expectations and also
points you to useful pages to get you started with coreboot. We highly
recommend reading it.

Are you interested in being a mentor? Great! Please also have a look at
our GSoC guide [6] and contact Felix Singer.

Would you like to support in a different way than being a mentor? Sure!
You could help with code reviews, discussing projects and working them
out (e.g. their scope and tasks) or just answering questions in our
chat rooms and mailing list.

We are looking forward to get in touch and discuss projects with you!

Your GSoC admins,

Felix, Martin and David


---
[1]
https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html
[2] https://doc.coreboot.org/community/forums.html
[3] https://doc.coreboot.org/contributing/project_ideas.html
[4]
https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ
[5] https://developers.google.com/open-source/gsoc/timeline
[6] https://doc.coreboot.org/contributing/gsoc.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #456] (Resolved) coreboot 4.19 tarballs have bad timestamps

[Felix Singer]

Issue #456 has been updated by Felix Singer.

Status changed from Feedback to Resolved

Thanks for confirming :)


Bug #456: coreboot 4.19 tarballs have bad timestamps
https://ticket.coreboot.org/issues/456#change-1421

* Author: Thierry Laurion
* Status: Resolved
* 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 - Other #314] (Closed (locked)) Please disable 'administrator approval' on ticket.coreboot.org

[Felix Singer]

Issue #314 has been updated by Felix Singer.

Status changed from Response Needed to Closed (locked)

@akjuxr3, you are doing very strong accusations against the project and the 
administrators of this service without providing any proof. Since I am 
administrating this service, I am taking this very serious and I really don't 
like getting wrong accusations. 

Not anything from what you are saying is true. The coreboot project tries to be 
inclusive as much as possible and people, me including, didn't know what to say 
or what to think while reading this. People are working hard and using their 
spare time, while having a day job, to give you the best possible experience. 
When we have to deal with things like this, then it's not just annoying or 
frustrating but it hurts, which might discourage people from spending their 
time on the project.

Patrick already explained the reason for that. We have to deal with spam 
accounts, rather some form of bots creating accounts, and this prevents them to 
flood this ticket system with spam. I'm trying to find ways to get rid of that, 
but there are not many options. So I do think this is a valid and reasonable 
solution so that the ticket system stays usable.

To be very clear: For the future, I am asking you to think twice before you do 
such accusations and to write your requests in a polite manner. I do not want 
to read wrong accusations again, especially when there is not a single proof 
given.

I'm going to close this ticket.


Other #314: Please disable 'administrator approval' on ticket.coreboot.org
https://ticket.coreboot.org/issues/314#change-1415

* Author: akjuxr3 akjuxr3
* Status: Closed (locked)
* 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 - Other #314] Please disable 'administrator approval' on ticket.coreboot.org

[Felix Singer]

Issue #314 has been updated by Felix Singer.

Tracker changed from Support to Other


Other #314: Please disable 'administrator approval' on ticket.coreboot.org
https://ticket.coreboot.org/issues/314#change-1414

* Author: akjuxr3 akjuxr3
* Status: Response Needed
* 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 - Refactoring #460] (New) Make mainboards using the variant concept

[Felix Singer]

Issue #460 has been reported by Felix Singer.


Refactoring #460: Make mainboards using the variant concept
https://ticket.coreboot.org/issues/460

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-02-14

* asrock/ivybridge
  * asrock/b75pro3-m
  * asrock/h77pro4-m

* asrock/haswell
  * asrock/b85m_pro4
  * asrock/h81m-hds



-- 
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 - Project ideas #451] Fix POST code handling

[Felix Singer]

Issue #451 has been updated by Felix Singer.



Estimated time set to 350.00 h





Project ideas #451: Fix POST code handling

https://ticket.coreboot.org/issues/451#change-1383



* Author: Felix Singer

* Status: New

* Priority: Normal

* Target version: none

* Start date: 2023-01-29



coreboot supports writing POST codes to I/O port 80. There are various Kconfigs 
that deal with POST codes, which don’t have effect on most platforms. The code 
to send POST codes is scattered in C and Assembly, some use functions, some use 
macros and others simply use the `outb` instruction. The POST codes are 
duplicated between stages and aren’t documented properly.



## Tasks



* Guard Kconfigs with a depends on to only show on supported platforms

* Remove duplicated Kconfigs

* Replace `outb(0x80, ...)` with calls to `post_code(...)`

* Update Documentation/POSTCODES

* Use defines from console/post_codes.h where possible

* Drop duplicated POST codes

* Make use of all possible 255 values



## Requirements



* Knowledge in the coreboot build system and the concept of stages

* Other knowledge: Little experience with C and x86 Assembly

* Hardware requirements: Nothing special



## Mentors



* Patrick Rudolph patrick.rudo...@9elements.com

* Christian Walter christian.wal...@9elements.com







-- 

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 - Project ideas #451] Fix POST code handling

[Felix Singer]

Issue #451 has been updated by Felix Singer.



Tracker changed from Bug to Project ideas





Project ideas #451: Fix POST code handling

https://ticket.coreboot.org/issues/451#change-1382



* Author: Felix Singer

* Status: New

* Priority: Normal

* Target version: none

* Start date: 2023-01-29



coreboot supports writing POST codes to I/O port 80. There are various Kconfigs 
that deal with POST codes, which don’t have effect on most platforms. The code 
to send POST codes is scattered in C and Assembly, some use functions, some use 
macros and others simply use the `outb` instruction. The POST codes are 
duplicated between stages and aren’t documented properly.



## Tasks



* Guard Kconfigs with a depends on to only show on supported platforms

* Remove duplicated Kconfigs

* Replace `outb(0x80, ...)` with calls to `post_code(...)`

* Update Documentation/POSTCODES

* Use defines from console/post_codes.h where possible

* Drop duplicated POST codes

* Make use of all possible 255 values



## Requirements



* Knowledge in the coreboot build system and the concept of stages

* Other knowledge: Little experience with C and x86 Assembly

* Hardware requirements: Nothing special



## Mentors



* Patrick Rudolph patrick.rudo...@9elements.com

* Christian Walter christian.wal...@9elements.com







-- 

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 #451] (New) Fix POST code handling

[Felix Singer]

Issue #451 has been reported by Felix Singer.





Bug #451: Fix POST code handling

https://ticket.coreboot.org/issues/451



* Author: Felix Singer

* Status: New

* Priority: Normal

* Target version: none

* Start date: 2023-01-29



coreboot supports writing POST codes to I/O port 80. There are various Kconfigs 
that deal with POST codes, which don’t have effect on most platforms. The code 
to send POST codes is scattered in C and Assembly, some use functions, some use 
macros and others simply use the `outb` instruction. The POST codes are 
duplicated between stages and aren’t documented properly.



## Tasks



* Guard Kconfigs with a depends on to only show on supported platforms

* Remove duplicated Kconfigs

* Replace `outb(0x80, ...)` with calls to `post_code(...)`

* Update Documentation/POSTCODES

* Use defines from console/post_codes.h where possible

* Drop duplicated POST codes

* Make use of all possible 255 values



## Requirements



* Knowledge in the coreboot build system and the concept of stages

* Other knowledge: Little experience with C and x86 Assembly

* Hardware requirements: Nothing special



## Mentors



* Patrick Rudolph patrick.rudo...@9elements.com

* Christian Walter christian.wal...@9elements.com







-- 

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 #449] ThinkPad T440p fail to start, continous beeping & LED blinking

[Felix Singer]

Issue #449 has been updated by Felix Singer.


Does this issue also occur on 4.19 and/or master? Would be great if you could 
test this.


Bug #449: ThinkPad T440p fail to start, continous beeping & LED blinking
https://ticket.coreboot.org/issues/449#change-1381

* Author: Crazy Fox
* Status: In Progress
* Priority: Normal
* Assignee: Angel Pons
* Category: board support
* Target version: 4.18
* Start date: 2023-01-14
* Affected versions: 4.18
* Related links: The USBAN error is:

```
[ERROR]  shift out of bounds src/northbridge/intel/haswell/pcie.c:85:22
[EMERG]  ubsan: unrecoverable error.
```
* Affected hardware: haswell

Hi, Team
Being corebooted before and works fine on 4.17.

After flashing 4.18 my t440p wont startup (black screen, constant beeping & LED 
blinking). I've tried and retried different nconfigs but result is the same. I 
know that it is lack of information, but I need to recover the laptop first to 
grab some logs from it.

Log from FT232H's debug is attached, the rest of info (defconfig, flashrom 
command etc. will upload soon)

---Files
coreboot_t440p_emerg.log (7.85 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: FOSDEM 2023 stand for coreboot/flashrom

[Felix Singer]

Hi Carl-Daniel and Christian,

thank you for doing the organization.

I will arrive early on Wednesday (1.02) and I have to leave on Sunday
around 16:00. Let me know if I can do or help you with anything. If
needed, I can definitely help during the build-up and also do some
stand duty.

Should we create a document with people who want to do stand duty? So
people can just fill in themselves.


Felix


On Tue, 2023-01-24 at 13:15 +0100, Carl-Daniel Hailfinger wrote:
> I'm happy to tell you that we'll have a combined coreboot/flashrom
> stand at FOSDEM.
> 
> When? Feb 4-5 2023
> Where? ULB, Brussels, Belgium
> Exact location? Building Aw, Level 1, Université libre de Bruxelles,
> Campus du Solbosch, Avenue Franklin D. Roosevelt 50, 1050 Bruxelles,
> Belgium
> Travel info: https://fosdem.org/2023/practical/transportation/
> List of stands: https://fosdem.org/2023/stands/
> 
> Who? You!
> Want to join? Sure! We would love to have 2+ people at the stand at
> all times. It helps even if you can only help us for one hour.
> 
> Practical info if you want to join/help out/talk to visitors:
> - Stand buildup has to be finished by Saturday 10:00
> - Stand teardown starts at Sunday 17:00
> - Stand duty on Saturday ends 19:00
> - Stand duty on Sunday starts 9:00
> - "Stand duty" is flexible (when and how long), but it would be cool
> if we can plan a little ahead.
> - If you bring something, please tell me via email
> - I will bring wired ethernet (if we're lucky and get something to
> plug in)+power
> - If you volunteer for stand duty, please tell me via email or show
> up sometime on Saturday so we can plan Sunday shifts.
> 
> More info? Christian Walter and I will be managing the stand/booth.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Documentation #450] Port over wiki pages to the new documentation

[Felix Singer]

Issue #450 has been updated by Felix Singer.

Description updated


Documentation #450: Port over wiki pages to the new documentation
https://ticket.coreboot.org/issues/450#change-1378

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-01-20

The [old coreboot wiki](https://www.coreboot.org/Welcome_to_coreboot) is being 
retired and it's replaced by https://doc.coreboot.org created with Sphinx. 
There are several wiki pages which are still not ported over.

This ticket is meant as a tracking ticket. Please create a separate ticket for 
each wiki page which needs a port and set this ticket as your parent ticket.

**Be aware that some wiki pages have content but for some reason the software 
doesn't render it. In that case, check the source page of it to see if it has 
content.**



-- 
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 - Documentation #450] Port over wiki pages to the new documentation

[Felix Singer]

Issue #450 has been updated by Felix Singer.

Tracker changed from Bug to Documentation


Documentation #450: Port over wiki pages to the new documentation
https://ticket.coreboot.org/issues/450#change-1377

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-01-20

The [old coreboot wiki](https://www.coreboot.org/Welcome_to_coreboot) is being 
retired and it's replaced by https://doc.coreboot.org created with Sphinx. 
There are several wiki pages which are still not ported over.

This ticket is meant as a tracking ticket. Please create a separate ticket for 
each wiki page which needs a port and set this ticket as your parent ticket.



-- 
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 #450] Port over wiki pages to the new documentation

[Felix Singer]

Issue #450 has been updated by Felix Singer.

Description updated


Bug #450: Port over wiki pages to the new documentation
https://ticket.coreboot.org/issues/450#change-1376

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-01-20

The [old coreboot wiki](https://www.coreboot.org/Welcome_to_coreboot) is being 
retired and it's replaced by https://doc.coreboot.org created with Sphinx. 
There are several wiki pages which are still not ported over.

This ticket is meant as a tracking ticket. Please create a separate ticket for 
each wiki page which needs a port and set this ticket as your parent ticket.



-- 
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 #450] (New) Port over wiki pages to the new documentation

[Felix Singer]

Issue #450 has been reported by Felix Singer.


Bug #450: Port over wiki pages to the new documentation
https://ticket.coreboot.org/issues/450

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-01-20

The [old coreboot wiki](https://www.coreboot.org/Welcome_to_coreboot) is being 
retired and it's replaced by https://doc.coreboot.org created with Sphinx. 
There are several wiki pages which are still not ported over.

This ticket is meant as a tracking ticket. Please create a separate ticket for 
each wiki page which needs a port.



-- 
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: coreboot 4.19 release next week

[Felix Singer]

Reminder: Unless any critical issues occur, coreboot 4.19 will be
tagged on the upcoming Monday.

Please test and let us know if there are any issues.


Felix

On Mon, 2023-01-09 at 09:52 -0700, coreboot org wrote:
> The coreboot 4.19 release is scheduled to be tagged this coming
> weekend  or next monday, barring any issues.
> 
> If there are any commits that you want to be included in the release,
> please mark them with the `coreboot_release_4.19` hashtag.
> 
> If you're not familiar with hashtags, you can set them by clicking
> the "show all" button at the top left of the screen in gerrit, then
> clicking the "hastags" edit icon.
> 
> As always, please test your boards and let the release team know if
> there are any problems that need to be fixed before the release.
> We're using the irc channel #coreboot_release to coordinate our
> activities.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Issue tracker version update / disabling of login methods

[Felix Singer]

On Fri, 2022-08-12 at 18:06 +0200, Nico Huber wrote:

> > I'm a bit unclear what you are proposing.
> > 
> > I'm also unclear whether, under your proposal, users without Google
> > accounts would be able to register or log in to the Redmine
> > instance.
> > 
> > Please can you clarify?
> 
> Currently one can login either with OpenID, a Google account or with
> a password that is stored on our Redmine host. With the intended
> changes, everybody will have to use a password.

Exactly.


// Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Issue tracker version update / disabling of login methods

[Felix Singer]

I'm not sure if anyone noticed that. So I wanted to push it again.

If nobody has any objections, I will disable the login methods at the
end of August.

// Felix


On Thu, 2022-08-04 at 22:26 +, Felix Singer wrote:
> the Redmine developers released version 5.0 some months ago and
> updating to this version will have some effects on us. So, I would
> like to open a thread to discuss these issues with you and how we
> deal with that situation.
> 
> Currently, we are on the 4.2 branch and it still gets security and
> bug fixes, but I can't tell at which point they will stop supporting
> it. 
> 
> We enabled the login over OpenID, which is implemented natively and
> not integrated over a plugin. With version 5.0, support for that was
> removed. I assume this is due to that the implementation is based on
> an older OpenID standard and there are not many users of it anymore
> (TM). The newer standard seems to be called "OpenID Connect", but
> it's not supported by Redmine.
> 
> Also, we are using a plugin which allows the login over a Google
> account. The compatibility of that plugin breaks with version 5.0.
> 
> The problem is that we have users for both and with version 5.0 they
> won't be able to use these methods anymore.
> 
> However, I have an idea for a solution. I took a look at the Redmine
> database and I played around with the Google login method. My tests
> showed that it creates a normal user account, as it is done with the
> registration, just with the little difference that no password is set
> disabling the login over password. These accounts also have an user
> name and an email address. As soon as I set a password, I was able to
> login using the user name.
> 
> So, my idea is that we just go with these changes and affected users
> use the functionality to reset their password, which means they will
> have a "normal" user account then. In preparation to that version
> update, we should disable these login methods so that no new users
> will make use of them.
> 
> Other ideas? What's your opinion?
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Issue tracker version update / disabling of login methods

[Felix Singer]

Hi all,

the Redmine developers released version 5.0 some months ago and
updating to this version will have some effects on us. So, I would like
to open a thread to discuss these issues with you and how we deal with
that situation.

Currently, we are on the 4.2 branch and it still gets security and bug
fixes, but I can't tell at which point they will stop supporting it. 

We enabled the login over OpenID, which is implemented natively and not
integrated over a plugin. With version 5.0, support for that was
removed. I assume this is due to that the implementation is based on an
older OpenID standard and there are not many users of it anymore (TM).
The newer standard seems to be called "OpenID Connect", but it's not
supported by Redmine.

Also, we are using a plugin which allows the login over a Google
account. The compatibility of that plugin breaks with version 5.0.

The problem is that we have users for both and with version 5.0 they
won't be able to use these methods anymore.

However, I have an idea for a solution. I took a look at the Redmine
database and I played around with the Google login method. My tests
showed that it creates a normal user account, as it is done with the
registration, just with the little difference that no password is set
disabling the login over password. These accounts also have an user
name and an email address. As soon as I set a password, I was able to
login using the user name.

So, my idea is that we just go with these changes and affected users
use the functionality to reset their password, which means they will
have a "normal" user account then. In preparation to that version
update, we should disable these login methods so that no new users will
make use of them.

Other ideas? What's your opinion?


// Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Removing Yabits as a payload - Now, or after 4.19 release?

[Felix Singer]

No objections. I think we should remove it now.

// Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Open Source Firmware Hackathon 2022

[Felix Singer]

Hi everyone,

after two crazy years, we decided it's time to do a open source
firmware hackathon. It will take place from 10th June - 12th June in
Darmstadt, Germany. For more details and tickets, have a look on this
site [1].

The hackathon will cover open source firmware projects, like coreboot,
oreboot, flashrom, LinuxBoot and any topics related to them. We have
two lecture rooms (2x 80 people) for discussions and presentations. 

Currently, only 17 tickets are left. Everyone is welcome, no matter if
beginner or professional.

24h breakfast, snacks and soft drinks are provided for free.

Would love to see you there!


// Felix

[1] https://osfw.foundation/events/osff-summer-hackathon-2022/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel Quark - a quick update

[Felix Singer]

On Fri, 2022-04-22 at 08:22 +, Andy Pont wrote:
> Thanks to the generosity of members of the list there are two Intel 
> Galileo boards, a Gen 1 and Gen 2, on their way to me which should 
> arrive towards the end of the month.
> 
> As soon as they get here I will start testing the various configs to
> see what works and what is broken.
> 
> -Andy.

So, will you also step up as a maintainer for it?


// Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #351] test issue for mailing list

[Felix Singer]

Issue #351 has been updated by Felix Singer.


test 2


Bug #351: test issue for mailing list
https://ticket.coreboot.org/issues/351#change-900

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2022-04-25

Testing the mailing list bot for coreboot.



-- 
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] Deprecation of the Intel Quark SoC

[Felix Singer]

Hi all,

to me it seems like the Intel Quark SoC has been unmaintained and
unused for a long time now. So I'm proposing to deprecate the support
for it with coreboot release 4.17 [1], in order to drop the support
with release 4.19 so that the community has less maintenance overhead.

Does anyone use this platform? Any opinions against this?


// Felix

[1] https://review.coreboot.org/c/coreboot/+/63283
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Introduction

[Felix Singer]

Hello vaibhav,

please make sure to reply to the mailing list and not only to me.

On Tue, 2022-03-29 at 12:52 +0530, vaibhav wrote:
> Hey Felix, Thank you for the resources,
> 
> > Did you find a project which is interesting for you?
> > 
> 
> Yes, I am interested in building `Fully support building coreboot with
> the Clang compiler`

As far as I know, Arthur Heymans is currently working on this and
according to some other people he is pretty far. Though, I don't know
much details. You can find his patches on Gerrit [1] (see the patch
list on the right). 

If you still want to work on this, we could try coordinating with him
and you do the remaining work. In case of this should be not enough for
GSoC, I can offer that you work on the "easy projects" [2] in addition,
specifically working on the scan-build issues and Coverity Scan issues.
These are issues found by a static analyzer, e.g. memory leaks. Have a
look at our documentation for more details [3]. 

Otherwise, you also could choose a project from our idea collection
[4]. How about reworking the FMAP generation?

> > Going through or documentation, building coreboot for QEMU and
> > playing
> > around with the code and the configuration is a good start. 
> > 
> 
>  I have been playing around and am starting to understand the codebase
> slightly better, Could you please explain in detail this Project Idea
> and how should I approach it so that I may be able to add Clang support
> for coreboot

Hm, not sure what I could explain in addition to the project
description [5]. Do you have any specific question?


// Felix

[1] https://review.coreboot.org/c/coreboot/+/62173
[2]
https://doc.coreboot.org/contributing/project_ideas.html#easy-projects
[3] https://doc.coreboot.org/infrastructure/coverity.html
[4]
https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ
[5]
https://doc.coreboot.org/contributing/project_ideas.html#fully-support-building-coreboot-with-the-clang-compiler
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Introduction

[Felix Singer]

Hello Vaibhav,

On Sat, 2022-03-12 at 01:14 +0530, vaibhav wrote:
> Hello everyone, I am Vaibhav, a 2nd-year Electrical Engineering
> student, willing to contribute to coreboot this summer.

Awesome. Welcome to coreboot! :)

Did you find a project which is interesting for you?


> Currently, I am intermediate in C and beginner in embedded systems
> I have started with going through the documentation and setting up my
> build environment, could anyone please guide me in what other concepts
> I should start looking into and how do I familiarize myself with
> coreboot and its codebase so that I may be able to make valuable
> contributions.

Going through or documentation, building coreboot for QEMU and playing
around with the code and the configuration is a good start. If you
would like to know more about how hardware "works", then the OS Dev
wiki [1] is great resource.

Of course, you also can join our chat rooms and ask questions there :)

Please note, that you should upload some patches to
review.coreboot.org, which is a requirement for the application. I
suggest you pick some little todos from the easy projects [2]. These
are also great to get familiar with the code base.


// Felix

[1] https://wiki.osdev.org/Main_Page
[2]
https://doc.coreboot.org/contributing/project_ideas.html#easy-projects
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot has been accepted for GSoC 2022

[Felix Singer]

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

Since I didn't get a response, did you find a project which is
interesting for you? :)


// Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [GSoC 2022] Interested student

[Felix Singer]

On Mon, 2022-03-14 at 20:39 +0300, Joursoir wrote:
> Hello everyone,
> 
> I would like to take part in the development of coreboot projects and
> become a GSoC 2022 contributor. I'm not a newbie in firmwares (I have
> experience with uefi, I'm familiar with bios). Now, to prepare
> myself, I study the coreboot documentation and source code.

Awesome! Welcome :)


> I find "Libpayload based memtest payload" and "Fix POST code
> handling" projects interesting. But I need some tips.
> 
> About the first one. To put it simply, the task is to study the
> memtest sources (memory checking mechanisms) and port it? And of
> course improve it, if possible.

Correct.


> I have more questions about the last one projects:
> 
> 1) Main goal is to make Kconfigs have effect on most platforms. For
> it we should maybe have deal with Kconfigs and replace to
> post_code(...) which refer to POST_IO and POST_IO_PORT. Right?

Unfortunately, I don't know much about this project and not sure if I
understood the question. First, all occurrences of outb() should be
replaced with post_code(). Then, post codes might not be supported by
all platforms. So they need to be guarded.


> 
> 2) For example, in `arch/x86/tables.c`, line 81:
> 
> post_code(0x9c);
> 
> coreboot has no documentation and macro for POST code 0x9c. So,
> should I find out what it means and write it in the documentation and
> add a macro?

Correct. Of course you also can ask people for help!


> 3) What does the task "Make use of all possible 255 values" mean?
> Does coreboot use all 255 values?

Maybe some post codes are used for different cases, which can be
confusing. Also, I'm thinking of making the post codes more fine
granular, so that they are more specific.

I will try to make people aware of your mail. Maybe someone else can
help :)


// Felix
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [GSOC-2022] Interested Applicant, Query regarding a project idea "Provide toolchain binaries"

[Felix Singer]

On Tue, 2022-03-15 at 04:39 +0530, Utkarsh M wrote:
> Hi everyone! My name is Utkarsh Mahajan. I'm a 2nd year ECE student
> from NITK, India.  I am passionate about Computer architecture and
> working on low level stuff. I recently found out about coreboot through
> gsoc. I am very much interested in contributing towards this
> repository.
> 
> Related to coreboot, I have a decent knowledge of c and just started
> playing with x86_64 assembly a month ago. So I recently started off by
> reading a bit of docs available on coreboot's website and tried out
> building an image file for i386 and testing it using QEMU. Which I was
> successfully able to do.

Welcome and awesome!


> Then I started exploring other parts of the docs and later tried
> understanding the code base but had a hard time understanding it so I
> am currently trying to understand specific tools used like kconfig and
> about makefiles from publicly available sources.

If you have any questions, please let us know.


> I'm specifically interested in the project "Provide toolchain
> binaries", But I wasn't able to understand what exactly is to be done
> in the project. As far from the written text, I understood that we need
> to provide package installers for the compiler so that for example
> coreboot could be installed from AUR helpers if an arch aur version was
> made.

Correct. Did you also see this document [1]?


> But then there's written about crossgcc, that we need something to
> replace it for individual architecture like x86_64 if i'm not wrong. If
> anyone could help me clarify about the project and could redirect me
> towards a few resources where I could gain enough knowledge to be able
> to work on coreboot and this project, it would be really helpful.

In order to build coreboot you need to build the toolchain for the
specific target architecture. This is not the architecture of your host
you are building on, but the architecture of the device you want to run
coreboot on. The command "make help" gives you an overview which target
architectures are supported.

The project is about packaging the toolchain for different distros,
like Arch, Debian/Ubuntu, openSUSE. Maybe even some *BSD (OpenBSD,
FreeBSD, ...) systems? :). So you need to get familiar with their
packaging system, how to make the package usable, 

I packaged the coreboot toolchain for NixOS [2][3]. Maybe it helps and
gives an idea of what needs to be done. Though, NixOS works a little
different than other distros.

So to get the coreboot version string and git revision appended to the
usual version string of the tools, I had to extend the buildgcc script
with a new command/parameter allowing to store the coreboot version
string in a file and hook it up in the postFetch phase, because there
the .git folder still exists. The .git folder is deleted at the end of
postFetch phase making the build reproducible.

After the postFetch phase, the internet connection is cut off, so that
no program can download any more things. This is another requirement
for reproducible builds.

So it's needed to prepare the environment first, which is done in the
postPatch phase. This phase hooks up stable.nix [4], which is just a
collection of the sources needed for the stable build of the toolchain.
The postPatch phase creates symlinks from their location to the place
where buildgcc expects the files.

Even it is hooked up after postFetch, the Nix evaluator is aware of
that and it will download all remote available ressources at the
beginning so that they are available later. I use a script [5] to
update the ressources in stable.nix when a new coreboot release is out.

In buildPhase I just read the coreboot version and run the command to
build the toolchain. I use the variable `DEST` so that the result is
moved to the final package folder later.

In my case, "common" is a function taking the argument "arch". So at
the bottom of default.nix, you can see that I iterate over different
target architectures and build the toolchain for them using the common
function. The result are different packages using the scheme coreboot-
toolchain., as you can see in the package search [2].

I hope that helps and that it isn't too confusing :)


// Felix

[1]
https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ/edit#
[2]
https://search.nixos.org/packages?channel=unstable=0=50=relevance=packages=coreboot-toolchain
[3]
https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/misc/coreboot-toolchain/default.nix
[4]
https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/misc/coreboot-toolchain/stable.nix
[5]
https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/tools/misc/coreboot-toolchain/update.sh
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot has been accepted for GSoC 2022

[Felix Singer]

Hi Ritul,

On Sun, 2022-03-13 at 09:03 +0530, ritul guru wrote:
> It's been an year I got involved in coreboot up streaming, can I get
> more information on kinds of project which I can take part.

thanks for your interest! You sent your email only to me. Please make
sure that you send the email to the mailing list the next time, so
others can also reply :)

Please have a look at our announcement [1]. Our project list and our
list with many new brainstormed ideas are mentioned there.

// Felix

[1]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/HLOAWLNMVFMP3YKIPEDARD6B2MD23PUF/

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: coreboot has been accepted for GSoC 2022

[Felix Singer]

Hi Ritul,

On Sun, 2022-03-13 at 09:03 +0530, ritul guru wrote:
> It's been an year I got involved in coreboot up streaming, can I get
> more information on kinds of project which I can take part.

thanks for your interest! You sent your email only to me. Please make
sure that you send the email to the mailing list the next time, so
others can also reply :)

Please have a look at our announcement [1]. Our project list and our
list with many new brainstormed ideas are mentioned there.

// Felix

[1]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/HLOAWLNMVFMP3YKIPEDARD6B2MD23PUF/

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] coreboot has been accepted for GSoC 2022

[Felix Singer]

Hello coreboot community,

We have great news: coreboot has been accepted for this year's Google
Summer of Code! Thanks to everyone who made this possible!

You can find our GSoC organization page here [1] (unfortunately,
newlines were removed from the description, but that’s not our fault).

Looking at the timeline [2], this means the next step is discussing
exciting projects. We have about a month for this, from now on until
April 3rd, and then the application phase starts.

It’s not too late to become a mentor! If you are interested, please
have a look at the mail [3] I have sent earlier. You also can help with
code reviews or working out a project (writing description, defining
project scope and tasks, ...). Every bit of help counts.

For people interested in being GSoC candidates, we set up a page [4]
for all kinds of information and documentation. Please have a look at
this, it’s really worth reading it :)

We prepared a list of projects [5] and we also started brainstorming
more project ideas [6]. No matter whether you want to participate as a
GSoC contributor or mentor, if you are interested in any of these, then
please let us know. Also, in case you have your own project idea, feel
free to reach out.

We are excited to have great discussions with you!

Your Org Admins,

Felix, Martin, David

[1]
https://summerofcode.withgoogle.com/programs/2022/organizations/coreboot
[2]
https://developers.google.com/open-source/gsoc/timeline#march_7_-_april_3
[3]
https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/PGKTAPC3UEPG722JBUBZYIQQ2UZSGRNA/
[4] https://doc.coreboot.org/contributing/gsoc.html
[5] https://doc.coreboot.org/contributing/project_ideas.html
[6]
https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Certificate expired

[Felix Singer]

On Fri, 2022-02-25 at 13:47 +, Galarazamba via coreboot wrote:
> I am trying to build a Heads x230-maximized.rom on Debian 10.4.0,
> 
> [...]
> 
> Updating my ca-certificates in Debian hasn't helped. Do you have any
> further ideas?

Try updating to Debian 11.

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #317] (Resolved) "make savedefconfig" broken

[Felix Singer]

Issue #317 has been updated by Felix Singer.

Status changed from In Progress to Resolved


Bug #317: "make savedefconfig" broken
https://ticket.coreboot.org/issues/317#change-883

* Author: Wladislav Artsimovich
* Status: Resolved
* Priority: Normal
* Start date: 2021-08-04

With Manjaro Linux and newest Updates, in coreboot git master, performing `make 
savedefconfig` without errors out with:

~~~
cp: missing destination file operand after 
'/home/gigi/coreboot-debug/Latest/.config'
Try 'cp --help' for more information.
make: *** [/home/gigi/coreboot-debug/Latest/util/kconfig/Makefile.inc:34: 
savedefconfig] Error 1
~~~
System info:

~~~

System:
  Host: gigi-pc Kernel: 5.10.53-1-MANJARO x86_64 bits: 64 compiler: gcc v: 
11.1.0 
  Desktop: Budgie 10.5.3 wm: budgie-wm dm: LightDM Distro: Manjaro Linux 
  base: Arch Linux 
CPU:
  Info: Quad Core model: Intel Core2 Extreme Q9300 bits: 64 type: MCP arch: 
Penryn 
  rev: A cache: L2: 6 MiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 bogomips: 20277 
  Speed: 2533 MHz min/max: 1600/2534 MHz boost: enabled Core speeds (MHz): 1: 
2533 
  2: 2534 3: 2534 4: 2534 
Graphics:
  Device-1: Intel Mobile 4 Series Integrated Graphics vendor: Lenovo driver: 
i915 
  v: kernel bus-ID: 00:02.0 chip-ID: 8086:2a42 
  Display: x11 server: X.Org 1.20.11 compositor: budgie-wm driver: loaded: 
intel 
  resolution: 1920x1200 s-dpi: 96 
  OpenGL: renderer: Mesa DRI Mobile Intel GM45 Express (CTG) v: 2.1 Mesa 21.1.5 
  direct render: Yes
~~~



-- 
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 #246] (Closed) Remove Jasperlake Preprod device IDs when Jasperlake Production SKU is available

[Felix Singer]

Issue #246 has been updated by Felix Singer.

Status changed from New to Closed


Bug #246: Remove Jasperlake Preprod device IDs when Jasperlake Production SKU 
is available
https://ticket.coreboot.org/issues/246#change-882

* Author: Aamir Bohra
* Status: Closed
* Priority: Normal
* Category: chipset configuration
* Start date: 2019-12-10

Initial Jasperlake develeopement code is adding Jasperlake Pre-Production SKU 
device IDs.
Once the production SOC SKU is available these IDs would become obsolete  and 
needs to cleaned up.

This Bug is intended to track the clean up once the Production SKU is available 
and Pre-Prod SKU phases out.
https://review.coreboot.org/c/coreboot/+/37434



-- 
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 #302] (Closed) You need to be root

[Felix Singer]

Issue #302 has been updated by Felix Singer.

Status changed from New to Closed

No response after 11 months. Closing.


Bug #302: You need to be root
https://ticket.coreboot.org/issues/302#change-881

* Author: Tim L
* Status: Closed
* Priority: Normal
* Start date: 2021-03-29

~~~
# ./intelmetool -m
iopl: Operation not permitted
You need to be root.

# id
uid=0(root) gid=0(root) groups=0(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 #48] (Closed) Linux fails to boot with embedded GRUB payload but works with embedded SeaBIOS payload

[Felix Singer]

Issue #48 has been updated by Felix Singer.

Status changed from New to Closed


Bug #48: Linux fails to boot with embedded GRUB payload but works with embedded 
SeaBIOS payload
https://ticket.coreboot.org/issues/48#change-880

* Author: Timothy Pearson
* Status: Closed
* Priority: Normal
* Category: os_handoff
* Start date: 2016-04-28

When booting an ASUS KGPE-D16 with the embedded GRUB payload Linux fails to 
acquire the ACPI IRQ and/or tables; booting the same board and OS image with 
the embedded SeaBIOS payload works fine.

Log of failed kernel boot from GRUB attached; logs of the successful kernel 
boot under SeaBIOS are forthcoming.

---Files
kgpe-d16-grub-linux-acpi-failure.log (21.2 KB)
kgpe-d16-seabios-linux-success.log (376 KB)
kgpe-d16-grub-linux-4.5-failure.log (366 KB)
kgpe-d16-seabios-linux-4.5-success.log (379 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 #93] (Closed) Romstage messages missing on Asus KGPE-D16

[Felix Singer]

Issue #93 has been updated by Felix Singer.



Status changed from New to Closed





Bug #93: Romstage messages missing on Asus KGPE-D16

https://ticket.coreboot.org/issues/93#change-879



* Author: Paul Menzel

* Status: Closed

* Priority: Normal

* Start date: 2017-01-31



With no CMOS battery (not tested with one yet), and using the user option table 
(CMOS/NVRAM) nothing is shown on the serial console until 40 s right before 
ramstage starts.



```

# This image was built using coreboot 4.5-917-g545edca

CONFIG_ANY_TOOLCHAIN=y

CONFIG_USE_OPTION_TABLE=y

CONFIG_COLLECT_TIMESTAMPS=y

CONFIG_USE_BLOBS=y

CONFIG_BOOTBLOCK_NORMAL=y

CONFIG_VENDOR_ASUS=y

CONFIG_BOARD_ASUS_KGPE_D16=y

CONFIG_NO_POST=y

CONFIG_COREBOOT_ROMSIZE_KB_16384=y

CONFIG_SOUTHBRIDGE_AMD_SB700_33MHZ_SPI=y

CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x4

CONFIG_DEFAULT_CONSOLE_LOGLEVEL_3=y

CONFIG_PAYLOAD_GRUB2=y

CONFIG_GRUB2_EXTRA_MODULES="boottime"

CONFIG_GRUB2_INCLUDE_RUNTIME_CONFIG_FILE=y

CONFIG_COREINFO_SECONDARY_PAYLOAD=y

CONFIG_MEMTEST_SECONDARY_PAYLOAD=y

CONFIG_MEMTEST_MASTER=y

CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y

CONFIG_TINT_SECONDARY_PAYLOAD=y

```



Please find the log from CBMEM console attached.



---Files

20170131–coreboot–asus_kgpe-d16–cbmem-c.txt (84.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 - Bug #321] (Resolved) NVME in X16 port issue

[Felix Singer]

Issue #321 has been updated by Felix Singer.

Status changed from New to Resolved


Bug #321: NVME in X16 port issue
https://ticket.coreboot.org/issues/321#change-878

* Author: Francois Ollonois
* Status: Resolved
* Priority: Normal
* Start date: 2021-09-07

I have used latest git version of coreboot to build a rom for my ASUS P5QL-EM.
I have some strange behavior:

I use a **X16 nvme** Adapter in the X16 graphic card slot. I also want to use 
an add-on gpu card (nvidia GT710 **PCIe X1**) to be able to use higher 
resolution displays.

With the bare board without any card everything works fine, but when I plug in 
the nvme adapter card with ssd, only the VGA output is working, but it is 
shiftet one character to the left. HDMI and DVI output are dead. It is possible 
to boot from the nvme ssd in this configuration. When the GT710 is pluged in, 
it is no longer possible to boot from the nvme ssd. (Read Error)


---Files
p5ql-em.config (17 KB)
coreboot_p5ql_with_nvme_hdmi (40.7 KB)
lspci_vendor.txt (61.9 KB)
lspci_coreboot_root2.txt (64.3 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 #249] (Closed) Clean up jasperlake_rvp devictree

[Felix Singer]

Issue #249 has been updated by Felix Singer.

Status changed from New to Closed


Bug #249: Clean up jasperlake_rvp devictree
https://ticket.coreboot.org/issues/249#change-877

* Author: Aamir Bohra
* Status: Closed
* Priority: Normal
* Assignee: Aamir Bohra
* Start date: 2019-12-27

Current jasperlake_rvp mainboard CL: 
https://review.coreboot.org/c/coreboot/+/37557 is based on copy from 
icelake_rvp .
Once this is merged, devicetree needs to be cleaned up as per JSL SOC. This bug 
tracks further jasperlake_rvp mainboard devicetree cleanup



-- 
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 #22] (Resolved) X230 native raminit failed

[Felix Singer]

Issue #22 has been updated by Felix Singer.

Status changed from Needs Testing to Resolved


Bug #22: X230 native raminit failed
https://ticket.coreboot.org/issues/22#change-876

* Author: Patrick Rudolph
* Status: Resolved
* Priority: Normal
* Assignee: Patrick Rudolph
* Start date: 2016-01-10

Native raminit failed with: "edge write discovery failed".
It's failing on channel 1 with two DIMMs installed, while it has no problems 
booting with a single DIMM.
The test fails on lane 1.
These are the Cvals of channel 1:
Cval: 1, 1, 0, 26
Cval: 1, 1, 1, 21
Cval: 1, 1, 2, 41
Cval: 1, 1, 3, 4d
Cval: 1, 1, 4, 4e
Cval: 1, 1, 5, 52
Cval: 1, 1, 6, 2c
Cval: 1, 1, 7, 5e

Cval: 1, 0, 0, 22
Cval: 1, 0, 1, 5e
Cval: 1, 0, 2, 3b
Cval: 1, 0, 3, 4a
Cval: 1, 0, 4, 4a
Cval: 1, 0, 5, 4c
Cval: 1, 0, 6, 29
Cval: 1, 0, 7, 5b

Values for the same lane are about the same (+- 6units), but only lane 1
shows a huge offset of 61.

---Files
x230_edge_write_discovery_failed.log (911 KB)
debugboot1.txt (61.7 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 #45] (Closed) F2A85-M fails to detect 24-32GB of RAM properly

[Felix Singer]

Issue #45 has been updated by Felix Singer.



Status changed from Response Needed to Closed



Closed. No response since 5 years.





Bug #45: F2A85-M fails to detect 24-32GB of RAM properly

https://ticket.coreboot.org/issues/45#change-875



* Author: Daniel Kulesz

* Status: Closed

* Priority: Normal

* Assignee: Kyösti Mälkki

* Start date: 2016-04-25



Hi,



I am running Coreboot 4.3 release on the Asus F2a85-M with 16GB of Crucial 
Ballistix Sport DDR-1600 DIMMs at 1,5V (2 sticks). When I populate the 
remaining RAM slots with another 2 sticks of the same type, the system does not 
boot to the Payload. When I put only 1 of the additional sticks in (so in total 
I should have 24GB), the system boots fine but I am seeing 78GB (!!) of memory 
detected on the operating system - see the attached output.



I don't have the coreboot config at hand, but I am just running basically 4.3 
release configured for this board together with the vgabios blob.



Is it safe to try the 4.4 prerelease to see if the bug can be reproduced there 
as well? I am just asking because I have no separate chip as backup nor the 
proper clip for hardware flashing this device.



---Files

memtotal.txt (1.21 KB)

coreboot.rom.bz2 (446 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 #37] (Closed) x220/native graphics: after some time the display shows only a one color blur image.

[Felix Singer]

Issue #37 has been updated by Felix Singer.

Status changed from Response Needed to Closed

Closed. No response since 5 years.


Bug #37: x220/native graphics: after some time the display shows only a one 
color blur image.
https://ticket.coreboot.org/issues/37#change-874

* Author: Alexander Couzens
* Status: Closed
* Priority: Normal
* Start date: 2016-03-12

After some time the display goes into a one color blur mode.
Everything but the display continues to work. Changing to another tty doesn't 
help.

Workaround: suspend/resume


[22770.401257] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* 
uncleared pch fifo underrun on pch transcoder A


---Files
config (349 Bytes)
dmesg_with_resume_with_native_graphics_with_failure (154 KB)
dmesg_with_resume_with_native_graphics_without_failure (126 KB)
dmesg_vgabios (126 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 #47] (Closed) Wsxga+ screens display Grub incorrectly

[Felix Singer]

Issue #47 has been updated by Felix Singer.

Status changed from Response Needed to Closed

Closed. No response since 5 years.


Bug #47: Wsxga+ screens display Grub incorrectly
https://ticket.coreboot.org/issues/47#change-873

* Author: Kete Foy
* Status: Closed
* Priority: Normal
* Start date: 2016-04-27

Wsxga+ screens partition Grub output into a few sections, and one of the 
sections is blank; so it's hard to use the Grub commandline.



-- 
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 #147] (Closed) Backlight level setting is not restored when the display wakes up from sleep on ThinkPad X230

[Felix Singer]

Issue #147 has been updated by Felix Singer.

Status changed from Feedback to Closed

Closed. No response since 3 years.


Bug #147: Backlight level setting is not restored when the display wakes up 
from sleep on ThinkPad X230
https://ticket.coreboot.org/issues/147#change-872

* Author: Tobis Greer
* Status: Closed
* Priority: Normal
* Start date: 2017-11-03

I am using Ubuntu 17.10, it also occurred on 17.04.

Whenever the display is sleeping (the laptop is still awake, just the display 
is off), and when it wakes up again (by moving the mouse, or issuing a 
keypress); then the backlight setting is at 100% regardless of what it was set 
at before the display went to sleep.

If I press the Fn+F8 key to set it again, one press is enough for the backlight 
level to go down several increments; back to where it was before the display 
turned off.

This didn't happen with the same Ubuntu install but running the stock BIOS.

For context, here is an excerpt from the mailing list:

~~~
this is a known issue. It actually was there all the time but only
got more visible with the introduction of ACPI/OpRegion for the inte-
grated GFX. Here is what I found out so far (on my ArchLinux):

w/o OpRegion:
  1. `acpi_video` driver gets loaded, systemd restores brightness from
 last shutdown.
  2. `i915` driver gets loaded, reads the current brightness.
  3. `i915` exposes backlight as `intel_backlight`, systemd restores
 brightness from last shutdown here as well.

Every time `i915` power cycles the backlight, it restores the value it
has seen when it was loaded.

w/ Opregion the order somehow changes to 2. 1. 3., now `i915` always
restores to 100% that it read before systemd restored the brightness.

A sane solution would be to extend XBCM in `src/drivers/intel/gma/acpi/
configure_brightness_levels.asl` to always notify `i915` when we change
the backlight through OpRegion mailbox 3.
~~~

Happy to provide more logs or details as required. Thanks!



-- 
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] GSoC 2022: Project ideas & call for mentors

[Felix Singer]

Hello coreboot community,

We are about to prepare our application for participating in Google
Summer of Code 2022 (FAQ [1]). The timeline is published here [2] and
Martin and David will help out as co-admin.

I have collected some project ideas from different places [3]. Some
might not be needed anymore, though. They still require a proper
description, a project type (~175 hrs or ~350 hrs) and they are missing
a mentor. If you want to make it happen and be a mentor yourself, if
you just want to help out and add the missing information or if you
have an own project idea, then please reply to this mail on the mailing
list and provide the following information:

  * Title
  * Project description
  * Project type (duration, ~175 hrs or ~350 hrs)
  * Required skills
  * Required hardware
  * Mentor

If you want to be a mentor, then please check the dates on the timeline
[2] and make sure that it works for you. There is also a short [4] and
a detailed [5] guide for the responsibilities of a mentor.

If you still have any questions, then please contact us.

Your GSoC admin,

Felix

[1] https://developers.google.com/open-source/gsoc/faq
[2] https://developers.google.com/open-source/gsoc/timeline
[3]
https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ
[4]
https://developers.google.com/open-source/gsoc/help/responsibilities#mentor_responsibilities
[5] https://google.github.io/gsocguides/mentor

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Denverton-NS refactoring

[Felix Singer]

Hello Jeff,

that sounds really great. Thanks!

> Not sure if the maintainers from Intel are still active or not, but
> I’m sending them an email to see. 

They aren't. The Intel "maintainers" told us they will work on
Denverton, while we were about to drop the Denverton support like a
year ago, but nothing happened since then.

So your patches are highly appreciated :)

> wondering what might be the best way to submit the refactor for
> easier review.

Hard to tell when we don't know what exactly has changed. I would say
just push whatever you have to Gerrit and then we will see. They can be
still rebased and reworked later :)

I suggest adding a topic to your patches (like
"denverton_refactoring"), if some aren't in the same relation chain. So
they are easier to find through the search.

// Felix

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Intel released first documentation on the PSE for Elkhart Lake SoC

[Felix Singer]

On Thu, 2021-12-09 at 11:40 +, Zeh, Werner wrote:
> As you know we are currently in discussion with Intel to get the PSE
> and its documentation on the Elkhart Lake SoC publicly available.
> Intel have now released some docs in this regard which can be
> accessed freely (see [1] and [2]). Feel free to use them as your use
> case requests.

Thanks a lot for your efforts!

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Question on flashrom 1.2

[Felix Singer]

Hi there,

this is the coreboot mailinglist. Please use the flashrom mailinglist
(flash...@flashrom.org) for any questions about flashrom.

Felix

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: "Private" changes on Gerrit are now disabled and removed

[Felix Singer]

In my experience, marking patches as WIP doesn't really help. I still
get reviews and comments for these patches. While I appreciate that,
it's also kind of annoying.

The private feature allows me to draft my patches and to get them in a
reviewable state without getting interrupted. Same if you want to work
with other people on something, which is meant to be public later. Also
this way, I don't create spam mails and I don't use the ressources of
the build infrastructure unnecessarily.

So I used the private feature a lot. I understand if people don't want
this to be enable again, but I rather would like to have this than not.
If people really want their patches to be private (for whatever
reasons), then they shouldn't upload them anywhere. Or they should use
their own repository, maybe on their own git server, where they have
full control over the access permissions. In my case, this gives me
more possibilities to collaborate with others and this is how I
understand it. It's easier to add someone as reviewer than "create a
gitlab/github account, pull the repository from there and create a pull
request if you want".

However, I think we should rather document that our Gerrit instance
isn't the right place for hosting others critical content or actual
private patches, that it shouldn't be used for such things and that
it's a possibility for structuring and collaboration.

Is it possible to rename the label to something else, so that it
doesn't sound so strong anymore? Like "hidden", for example. Or does
this need changes in its code?

// Felix

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What should we do about freenode IRC services?

[Felix Singer]

On Tue, 2021-05-25 at 15:00 +0200, Patrick Georgi via coreboot wrote:
> So, what should we do?

In my opinion, we should move away as long as we are able to. They are
taking over channels which mention or reference any other chat service
in their topic. See [1][2][3][4]. They might get other crazy ideas in
the future (or maybe already have), who knows.

I would still like to have the possibility to chat over IRC. We
shouldn't do a "hard" move to another chat service, like Matrix or
Mattermost, since I think there is not enough time to evaluate all non-
IRC options and we shouldn't wait much longer. We should rather remain
on IRC and use a bridge. This way, people will have enough time to get
familiar with the alternative chat service, if we decide (at some later
point) to move away from IRC completely.

Some thoughts regarding libera <-> OFTC:
   - The services on libera work like the ones on freenode, while OFTC
works a bit different afaik.
   - The Matrix bridge for libera is WIP. I am not sure if OFTC has
one. I couldn't find anything on their website.

I am registered on libera and OFTC and I am fine with both, but I don't
really use OFTC. Both networks already have a coreboot channel created
by people related to the project. Currently, on libera there are 46
people and on OFTC 2 people (me included).

So I would say let's move to libera.

// Felix

[1] https://twitter.com/GrapheneOS/status/1397401277072646145
[2] https://twitter.com/GrapheneOS/status/1397402818324140033
[3] https://twitter.com/mjg59/status/1397389042619097095
[4] https://twitter.com/andy_kelley/status/1397388932367601665

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: CBFS pointer problem with SeaBios and Apollo Lake platform

[Felix Singer]

Hi,

On Thu, 2020-04-23 at 08:15 +, Wolfgang Kamp - datakamp wrote: 
> Am I correct that the problem still exists that SeaBios can’t find
> the CBFS in apl platform?

I used this as workaround: 
https://review.coreboot.org/c/coreboot/+/32327

It requires that you put the CBFS at the end of your partitions.

-- 
Best regards / Mit freundlichen Grüßen

Felix Singer


signature.asc
Description: This is a digitally signed message part
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org