Hi everybody,
in today's leadership meeting we discussed whether we should hire
technical writers to improve our documentation. While the situation
already got a lot better since we moved to the Documentation/ directory
instead of the wiki, it's still painfully obvious (at least to me)
that we're
We moved the other thread off-list, but the issue was that there's a https
proxy in the way that
terminates SSL connections.
I documented the approach to deal with that in
https://review.coreboot.org/c/coreboot/+/37599
Patrick
Am So., 8. Dez. 2019 um 09:39 Uhr schrieb Mike Banon :
> My guess
Note that the setting is per-clone by default, so if you set up coreboot to
be without sslVerify, that doesn't apply to the board_status repo unless
you also used --global.
Am Mo., 9. Dez. 2019 um 11:11 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:
>
> >We moved the other thread
Am Mo., 9. Dez. 2019 um 11:51 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:
> >Note that the setting is per-clone by default, so if you set up coreboot
> to be without sslVerify, that doesn't apply to the board_status repo unless
> you also used --global.
>
> Yes, I have it
Am Mo., 9. Dez. 2019 um 19:02 Uhr schrieb Seth Rosenblatt <
s...@the-parallax.com>:
> I wasn't able to find the security@ alias, otherwise would've emailed
> y'all there. I didn't hear back before publication but happy to make any
> corrections if needed. I'm also willing to include a statement
Am Do., 5. Dez. 2019 um 15:22 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:
> One noob question. Can I push a change from a commit
> (f77f2c79c2bb898c123ffe89a0bd1acb5362afc5)
> not the master? From this commit I can make it boot but from the last
> there are
> a lot of changes to
Am Fr., 6. Dez. 2019 um 17:23 Uhr schrieb Jose Trujillo via coreboot <
coreboot@coreboot.org>:
> Added variable: 0x0, val size: 0
> Found variable: key size: 0x0, val size: 0
>
> Several minutes later boots normal.
> If someone here knows how to fix it or suspect which could be the reason
>
Hi Jorge,
Am Do., 5. Dez. 2019 um 12:53 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:
> and in setting I can see my GitHub user (jorgefm1900), the ID, etc... Then
> under 'HTTP Credentials' I've press
>
the 'GENERATE NEW PASSWORD' button and the string I get is what I use to
>
On Mon, Nov 04, 2019 at 09:30:34AM -0500, Patrick Georgi wrote:
> I'm planning to release coreboot 4.11 two weeks from today, Nov 18th.
This has been deferred to tomorrow, Nov 19th.
My basic functionality tests with current master are looking good,
but there are two issues for which I'm trying to
It's my pleasure to announce that coreboot 4.11 was just released.
Release notes follow. Note that there are deprecations listed that will
be in effect immediately. The first two (Fam12 and MIPS) probably don't
affect anybody, but the third item has quite a lot of ripple effect.
I was
On Sun, Nov 24, 2019 at 11:00:00AM +, awokd via coreboot wrote:
> Could a Coreboot Coverity admin please re-run the scan against master?
Done.
> Looks like the last analyzed version was from Sep 24, 2019. I would like
> to see what AGESA issues remain.
Thanks for the heads-up!
I'm not quite
Am Do., 5. Dez. 2019 um 12:16 Uhr schrieb Jorge Fernandez Monteagudo <
jorg...@cirsa.com>:
> > You can try setting up SSH key on the gerrit account and change the git
> remote to SSH instead of HTTPS.
> Sorry, we only have access to http/https ports... maybe I have a
> certificate's problem...
>
Nico Huber via coreboot schrieb am So., 26. Jan.
2020, 02:07:
> Hello again,
>
> so, we have Jenkins that runs build tests on our master branch. That
> makes working together on a huge project much easier. However, do we
> have a rule that all the code should be build tested? and if not,
>
Hi Marshall,
thanks for that cohesive report and insight into your development process
and the trade-offs involved.
Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson <
marshalldawson...@gmail.com>:
> Instead, please give me the opportunity to review any of your changes that
> touch the
On Mon, Jan 27, 2020 at 04:24:00PM -0600, Matt DeVillier wrote:
> having a src/mainboard/stub/ for **all** SoC might not be a bad idea,
> especially if it were to select less common/non-default options that other
> in-tree boards don't select by default, to ensure full coverage of all SoC
>
Hi everybody,
one thing that became clear to me in the recent (and not-so-recent)
discussions broadly related to coding style, code duplication, code
submission strategies, documentation requirements and similar things
is that there have to be many different styles of approaching coreboot
Am Di., 28. Jan. 2020 um 08:03 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:
> Please correct me if I'm way off base with that example. The stubs
> Patrick proposed in the other thread might help address the issue,
> however it can also mean adding code which exists only to satisfy
David Hendricks schrieb am Mi., 29. Jan. 2020,
00:51:
> we'd first need to invent a way to
> send an electric shock thru the keyboard to users who complain to (or
> about) Intel when something goes wrong with the code.
>
That may have been necessary in the era of the fdiv bug but I'm not sure
Am Do., 9. Jan. 2020 um 06:46 Uhr schrieb Mike Banon :
> It would be nice if the deleted commits get moved to some archive
> outside of Gerrit instead of being simply removed, to ensure that if
> anyone else is interested in these commits, they could be restored.
That's not easily done and I
Am Fr., 6. März 2020 um 12:15 Uhr schrieb Piotr Król :
> If the community keeps our reviews not merged, we
> cannot use that as proof of our engagement and quality.
[...]
> This doesn't contribute to project health.
>
Indeed. Looking into Gerrit, we have >1000 commits open for coreboot.
Some
Hi everybody,
since we're invited to participate in this year's GSoC and since students
can send their project proposals starting next week, I guess now is the
time to register potential mentors with the system, so we can triage and
assign proposals efficiently.
If helping a student get up to
Hi everybody,
we just had our project leadership meeting and I brought up the Google
Season of Docs[0] programme which is similar to Summer of Code but
for documentation.
(Note to meeting attendants: I mentioned that the application deadline
for projects has already passed, but I was wrong about
Hi everybody,
There's some fine work by Jan on Gerrit on the issue of adding unit testing
infrastructure to our tree and I'd like to see it merged soon.
So far, most feedback was by Google folks so this is a heads up for
everybody (and especially those not at Google) to take a look and offer
Hi everybody,
it's that time of year again: we should look into cutting a
release. Not because there's anything noteworthy that we should bring
out (although there certainly is), but because we have a 6-monthly
cadence of giving our tree a new number and pushing out tarballs and
press releases.
Hi Eduardo,
Am Mo., 11. Mai 2020 um 03:24 Uhr schrieb edbatalha--- via coreboot <
coreboot@coreboot.org>:
> About 2 months ago I discovered that it is supported by coreboot so I
> thought it would be fun to experiment with it.
>
Well, welcome!
> 2)
> I then decided to try out Windows XP but
Peter Stuge schrieb am Sa., 16. Mai 2020, 15:39:
> Holy moly..
>
Indeed...
All I could find was "prepare for 64 bit resources". That is beyond weak.
>
To people dealing both with somewhat modern hardware and coreboot, it is
well known that the resource allocator has a few crucial weaknesses in
Hi Sindhoor,
Welcome to coreboot!
Would you mind spending a few words on what you'll be working on? It's
something about POST codes but there's little more than that available
about your project, and there has been some interest in your work already.
Thanks,
Patrick
--
Google Germany GmbH,
Hi again,
A while I ago I announced my intent to do a new coreboot
release. This is slated to happen next Monday, so we're now at
the "~1 week prior to release" point of our release checklist (at
https://doc.coreboot.org/releases/checklist.html).
So as a reminder: Please test the devices you
Hi everybody,
during last week's issue with the resource allocator there have been some
remarks about how the change seemed practically invisible despite being on
Gerrit for 2 months and some people suggested that it would be useful to
have better documentation with such changes on why they're
Hi everybody,
I just release coreboot 4.12, with release notes as follows:
Since 4.11 there were 2692 new commits by over 190 developers and of
these, 59 contributed for the first time, which is quite an amazing
increase.
Thank you to all developers who again helped made coreboot better
than
Hi Sindhoor,
Am Di., 24. März 2020 um 08:19 Uhr schrieb Sindhoor Tilak <
sindh...@sin9yt.net>:
>This is my first time here applying for GSoC.
>
> I'm interested in couple of ideas posted. I wanted to know if multiple
> proposals are accepted?
>
If you have multiple proposals, feel free to
Am Fr., 4. Sept. 2020 um 10:56 Uhr schrieb Nico Huber :
> I would expect the opposite. At least for all coreboot revisions that
>
use a Git submodule. Those point to commits, not branches, and hence
> should always work as long as the branch history is kept in tact
> upstream.
>
Indeed: As long
Hi everybody,
I heard about a project interested int creating coreboot compatible
open hardware. While that effort isn't ready to make any announcement,
questions came up about where to host such a project.
There's lots of open hardware out there already, but it's often
based on not-quite open
On Thu, Sep 24, 2020 at 01:06:13PM +0200, Christian Walter wrote:
> what does "coreboot compatible open hardware" means here? Do we have
> some kind of specification for this or does that "just" means no blobs
> at all?
No specification as yet, I wrote that email with the intent to start
a
Hi everybody,
Just a quick heads up: the unit tests in tests/ are now built and run on
every commit pushed to review.coreboot.org.
Consider this a good opportunity to improve our stability by contributing
tests! Jan is writing a tutorial on writing tests that you can find for now
at
Am Di., 2. Juni 2020 um 17:50 Uhr schrieb Jeremy Jackson :
> Below is a patch that does what I want for one of the points I
> mentioned. Comments? Does this interfere with a different use case?
>
I'd say that change is reasonable. Care to push it to review.coreboot.org
or should somebody else
On Wed, Jul 08, 2020 at 06:51:41PM +0200, Daniel Kulesz via coreboot wrote:
> I wanted to reply in the Redmine issue tracker to a comment posted
> by Patrick Georgi [1], however, it seems like I can only open new
> issues and edit my own issue as well but not comment or reply to
> comments. At
Am Mo., 15. Juni 2020 um 22:27 Uhr schrieb Gregg Levine <
gregg.drw...@gmail.com>:
> Initialized empty Git repository in /usr/src/lobos/work4/coreboot/.git/
> fatal: https://review.coreboot.org/coreboot.git/info/refs download
> error - The requested URL returned error: 406
>
Am Mi., 17. Juni 2020 um 02:47 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> Patrick, any further concerns from your side? If not, would you mind
> creating a new repository for this? I can write the patches to move
> blobs and adjust the Makefiles afterwards.
>
I will create a repo for
Am Mi., 10. Juni 2020 um 03:43 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> > Clearly, the rules should be the same for all blobs, so if
> > some blobs with language like this are already in the repository, it
> > shouldn't be grounds to reject new blobs from landing.
It's not unheard of
Hi everybody,
in last Wednesdays' leadership meeting we've been discussing how to
deal with language in our code and community. I offered to report on
our results and to start the wider discussion and so that's the aim
of this email.
You might have heard about calls to avoid certain terminology
Am Di., 12. Jan. 2021 um 09:47 Uhr schrieb Alif Ilhan :
> Well, should I share the code? But I am trying with Pineview raminit
> codes, both the MRC.bin and native one. The bios session document mentioned
> "Cedar View uses the same MRC build environment as Pineview"
>
We welcome contributions
Am Mi., 25. Nov. 2020 um 15:57 Uhr schrieb :
> On 2020-11-24 03:05, Andy Pont wrote:
> > Is there an idiots guide to the definitions in devicetree.cb? Trying
> > to make sense of the USB and PCIe configuration stuff.
>
https://doc.coreboot.org/acpi/devicetree.html describes some aspects but
it's
Am So., 15. Nov. 2020 um 19:43 Uhr schrieb Matt DeVillier <
matt.devill...@gmail.com>:
> if it were as simple as building Tianocore with SeaBIOS as the CSM, that
> would be the default option offered, but unfortunately it's not. The
> neither Tianocore package (the default CorebootPayloadPkg, nor
Am Do., 19. Nov. 2020 um 18:32 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > > My argument is solely on complexity, but please don't trust that hash
> too
> > > much.
> >
> > If I shouldn't trust
> > "16 commit 4c523ed10
Am Mi., 18. Nov. 2020 um 09:14 Uhr schrieb David Hendricks <
david.hendri...@gmail.com>:
> or is the problem here just the fact that the hashing library is part of a
> submodule?
>
If it's the submodule that is in question here, we _could_ import vboot as
a subtree (and compatibly, too!),
Am Di., 17. Nov. 2020 um 18:54 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > coreboot doesn't, cbfstool does.
>
> If that were the case things would already be a lot better!
>
> Alas, coreboot unconditionally requires vboot in these files:
>
Oops, I fo
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T02
Am Mi., 18. Nov. 2020 um 22:15 Uhr schrieb bzt :
> I believe you are both unnecessarily overcomplicate this. The way I
> see it the only issue here is a few missing ifdef guards for
> CONFIG_VBOOT in cbfs, that's all. Quite straightforward to solve.
>
CONFIG_VBOOT enables vboot, the verified boot
Am Mi., 18. Nov. 2020 um 22:03 Uhr schrieb Nico Huber :
> The vboot dependency has been a PITA for a while. I'll happily accept
> patches that make it less of a pain even if that means a little more
> maintenance effort. I'd even accept a local hash implementation.
That's an option. That isn't
Am Mi., 18. Nov. 2020 um 23:54 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> because unlike everything
> else you need to build coreboot there seems to be no way to get an ADA
> toolchain from crossgcc.
gnat (gcc's Ada implementation) needs an Ada implementation to bootstrap
(just like
Am Do., 19. Nov. 2020 um 01:26 Uhr schrieb Peter Stuge :
> > the Git SHA of the submodule HEAD is stored in the main coreboot repo.
>
> My argument is solely on complexity, but please don't trust that hash too
> much.
>
If I shouldn't trust
"16 commit 4c523ed10f25de872ac0513ebd6ca53d3970b9de
Am Di., 17. Nov. 2020 um 05:06 Uhr schrieb Peter Stuge :
> It's absurd to me that coreboot would require any routines out of any
> submodule for a build which will not use those routines.
coreboot doesn't, cbfstool does.
One purpose of Kconfig is to ensure that only what's neccessary gets
Hi everybody,
when announcing today's leadership meeting on IRC I got some replies to the
tune of "oh no, Google!" as the meeting minutes are recorded on Google Docs
and the meeting itself is held using Google Meet.
Note that both are set up to be usable without a Google account, so the
impact
Hi everybody,
There has been some talk recently in a smaller group where coreboot needs
to improve the most in public perception, and how to get there.
Consensus has been that we're doing a pretty bad job at promoting all the
hardware that we support in each coreboot version.
There's
Hi everybody,
I still plan to do the coreboot release on Monday (or, if things are really
bad, on Tuesday), even though I'm somewhat behind on our checklist.
This means we are at the
https://doc.coreboot.org/releases/checklist.html#week-prior-to-release
stage.
Therefore, if you have hardware and
Am Do., 6. Mai 2021 um 14:03 Uhr schrieb Piotr Król :
> If 3mdeb maintains some boards, we already testing those and would be
> glad to hook, in secure way, to patch testing system, but I would like
> to know where is interface documentation so I can evaluate cost of
> integration and convince
Hi Julius,
the syncer's configuration for that repo was wrong in a couple of places, I
fixed it this morning.
Regards,
Patrick
Am Do., 13. Mai 2021 um 01:55 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> Hi Patrick, Martin,
>
> The coreboot.org mirror of the arm-trusted-firmware repo
>
Am Sa., 8. Mai 2021 um 03:08 Uhr schrieb Julius Werner :
> I understand that you might like to have both [features and stability] but
> I think that's just fundamentally impossible -- big new features just tend
> to require deep, invasive changes.
+1
> I think we could encourage that, I don't
Hi everybody,
you might have heard that freenode.org recently changed management under
weird circumstances. Given that we use their services for our project
chat, this concerns us as well.
In last week's leadership meeting we had a wide variety of opinions: To
go for libera.chat (a network
27. Mai 2021 11:44, "Angel Pons" schrieb:
>> On Tue, May 25, 2021 at 6:01 AM Patrick Georgi via coreboot
>> wrote:
>>> So, what should we do?
>
> I'd suggest moving to Libera. I think the Matrix bridge to Libera is
> running now.
It is: #coreboot:libera.
Am 28.05.2021 um 07:54 schrieb Shawn C:
Nice, I wouldn't use libera.chat since they banned all tor traffic by default.
OFTC respect more of user privacy but seems nobody are willing to use. Then
Matrix is a good option. Thanks.
They seem to have a dedicated tor service now, described at
gitiles#106 points to https://github.com/google/gitiles/issues/7 which
outlines the concern of delivering arbitrary data from an authenticated
domain.
I believe GitHub moved its "raw" output to a separate domain for the same
reason, e.g.
Hi everybody,
This email starts the release process for coreboot 4.14, so we're now at
the "~2 weeks prior to release" step in our
https://doc.coreboot.org/releases/checklist.html
As usual, our releases don't denote any particular feature or stability
milestone, they only serve two purposes:
1.
Hi Arthur,
The master header is a legacy thing and I'm in favor of removing it. That
said, as you and Michal mentioned, there's some work to do first. I started
https://ticket.coreboot.org/issues/306 to help track what's missing.
Patrick
Am Mi., 28. Apr. 2021 um 08:42 Uhr schrieb Arthur
Am Do., 22. Apr. 2021 um 22:58 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > tree-wide changes
> ..
> > there may be other approaches on how to make development easier
>
> I'm a big fan of semantic patching as provided by coccinelle and used
&
Am Di., 9. Feb. 2021 um 11:34 Uhr schrieb Arthur Heymans <
arthur.heym...@9elements.com>:
> So TL;DR:
> - Is (temporarily) adding a tool to the blobs repo ok?
>
If it matches the requirements of the blobs repo wrt. license terms and
documentation, I don't see why not from a formal perspective.
Hello everybody,
https://review.coreboot.org/c/coreboot/+/51825 proposes getting rid of the
rule to make if-statement blocks (and the like) as short as possible.
The rationale is to encourage a style that avoids subtle bugs which then
need to be found by tooling such as Coverity Scan and fixed by
Am Di., 6. Apr. 2021 um 21:21 Uhr schrieb Peter Stuge :
> Patrick Georgi via coreboot wrote:
> > Any objections to moving the code out there that has no other upstream
> > (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> > while moving in code from
Am Mi., 7. Apr. 2021 um 01:12 Uhr schrieb Julius Werner <
jwer...@chromium.org>:
> I think we still need to have a difference between hacky vendor stuff
> and normal coreboot code. For example, the Eltan mboot stuff is
> something we didn't really want to have in coreboot in that form, and
> so
Hi everybody,
We recently landed a change (https://review.coreboot.org/51827) to be more
selective which parts of src/vendorcode are checked for coding style
because some areas are really coreboot code "by vendors".
The original purpose of that subhierarchy was to isolate code we draw in
from
Am Do., 18. März 2021 um 04:04 Uhr schrieb Tobias Wiese <
tob...@tobiaswiese.com>:
> Actually since HyperKitty Version 1.3.4 the HYPERKITTY_ALLOW_WEB_POSTING
> setting should do that.
> This might prevent further confusion for others.
>
The last time I looked that didn't exist yet, but I disabled
Dear Mr. Kunze,
Am Di., 16. März 2021 um 17:43 Uhr schrieb web25322986p1 <
gottfried.ku...@fanfara.de>:
> Trotz Anmeldung bei der Mailiglist (bin eingeloggt) kann ich jedoch keinen
> Thread beginnen. Ich erhalte stets:
> *Error 404 not found.
> *
>
> We disabled the mail editor in hyperkitty
Hi Julius,
https://qa.coreboot.org/job/coreboot-boot-test/ sends off ToT builds to
9esec's Lava system where they are run on some virtual and real devices.
See for example the comments to
https://review.coreboot.org/c/coreboot/+/51189 where Lava reports passing
on 5 qemu configs and 3 real
Hi Vedant,
coreboot has applied to this year's GSoC but GSoC still has to decide on
the projects they want to host: That will be announced on March 9.
Patrick
Am Sa., 20. Feb. 2021 um 07:40 Uhr schrieb :
> Hi, I am interested to apply to gsoc2020, is coreboot going to apply in
> gsoc 2021?
>
Hi Hritik Vijay,
we applied to GSoC but they will only announce the projects that will
participate this year on March 9.
Regards,
Patrick
Am Fr., 19. Feb. 2021 um 09:52 Uhr schrieb Hritik Vijay via coreboot <
coreboot@coreboot.org>:
> Hi
> Coreboot appeared last year in the GSoC initiative, I
Hi Enrico,
(list to bcc)
not speaking about the technical difficulties you face with golang or the
general topic of blob use here, just one thing:
Don't post conspiracy theories here. Well, two things: We also do not
punching here (except for cards, maybe, if we're in the mood for some retro
Hi everybody,
In our leadership meetings we repeatedly had companies using coreboot look
for qualified staff. In response this created a job site at coreboot.org,
linked prominently from our landing page, accessible at
https://coreboot.org/jobs.html
So if you're looking for a coreboot related
Hi everybody,
As we're encountering a spam campaign right now by a sufficiently motivated
actor to get through our filters I put the mailing list on moderation until
this silliness subsides.
For this reason delivery of mails sent to this list may be delayed.
Thanks for your patience,
Patrick
--
Hi everybody,
There have been some issues with the mailing lists hosted at coreboot.org
(spanning multiple projects: coreboot, flashrom, seabios and openbios)
related to configuration changes in response to our precious little
spammer. As a result some people have seen mailing list delivery to
Am Mo., 22. Feb. 2021 um 12:31 Uhr schrieb Vedant Paranjape <
vedantparanjape160...@gmail.com>:
> Thanks for the update. I joined coreboot IRC, it doesn't seem active. Any
> other communication channel to lookout for?
>
The channel is reasonably active for a medium size project like coreboot,
but
Hi everybody,
In our leadership meeting[1] we discussed how we should deal with tree-wide
changes (ranging from "new file header" to "some API is gone now"). The
concern was that right now, anything can change at any time, making local
development harder.
There have been a few ideas but nothing
Hi Ray,
Am Fr., 17. Sept. 2021 um 18:43 Uhr schrieb Ni, Ray :
> If yes, is there a recommended memory map (where is stack, where is
> coreboot ramstage, where is payload)?
>
ramstage is relocatable these days: romstage/postcar loads it near the top
of memory. ramstage's stack is kept in the
Hi Branden,
the issue should be resolved. Thanks for bringing it up!
Patrick
Am Di., 21. Sept. 2021 um 19:22 Uhr schrieb Branden Waldner <
scruff...@gmail.com>:
> I was just checking the mailing list archive and noticed that it isn't
> showing any new messages since September 9.
>
> I wasn't
> It's easy to let the joy of building a build system overwhelm the
>> actual goals of a project. coreboot is not about being a build system.
>> It's easy to fall into the trap of creating an ever more complex
>> system that is more than is needed.
>>
>> On Thu, Sep
Hi everybody,
To facilitate cooperation on UEFI-as-a-payload work, we established a
mirror of tianocore's edk2 repo at https://review.coreboot.org/edk2. Unlike
other mirrors on review.coreboot.org, it's open for development.
It's updated regularly, but the default branch that we set up,
For coreboot related jobs there's https://www.coreboot.org/jobs.html
More generally there's a channel called "firmware-jobs" in the OSFW slack:
https://osfw.slack.com/archives/C029KQWBWJZ which has an invite-bot at
https://slack.osfw.dev/
Am Di., 19. Okt. 2021 um 20:04 Uhr schrieb Jonathan
Am Mi., 20. Okt. 2021 um 11:04 Uhr schrieb Sukanto Ghosh via coreboot <
coreboot@coreboot.org>:
> Does the current coreboot/arm64 port allow executing only the ramstage of
> coreboot (say as a means of reducing the coreboot binary footprint) ?
>
I think that's really the gist of your inquiry, so
Am Mi., 20. Okt. 2021 um 11:04 Uhr schrieb Sukanto Ghosh via coreboot <
coreboot@coreboot.org>:
> We have couple of queries regarding the current support and future
> direction of arm64 port of coreboot:
>
>
>1. Does the current coreboot/arm64 execute post BL31 stage (assuming a
>separate
Am Sa., 16. Okt. 2021 um 02:40 Uhr schrieb ron minnich :
> Contest is easy to set up, easy to run, it's
> getting contributors. I understand it's a commitment of a day or so to
> figure out, but it's worth it in our experience. It's just not that
> hard.
>
> I believe starting down the python
Am Fr., 15. Okt. 2021 um 19:50 Uhr schrieb Ricardo Quesada <
ricar...@google.com>:
> In the meantime, would it make sense, as Jack mentioned, to land my change
> [1] as it is? It is small/simple and it only has ~160 LoC Python.
> For comparison, other util are using Python: util/qualcomm has
Am Mi., 13. Okt. 2021 um 20:51 Uhr schrieb Peter Stuge :
> > Linux is expecting more and more to use EFI supplied interfaces (UEFI
> > Boot Services in particular, even if many are stubbed out) so like it or
> > not, we’re going to need to support these interfaces.
>
> LOL!
>
The fun part about
Hi Selma,
It might help to know what kind of build failures these are. Could you post
them somewhere (e.g. ticket.coreboot.org) for discussion?
Regards,
Patrick
Am Sa., 25. Sept. 2021 um 02:22 Uhr schrieb Bensaid, Selma <
selma.bens...@intel.com>:
> Hi,
>
> We are facing build failure due to
Hi everybody,
Historically, coreboot avoided depending on python too much (we got rid of
an entire python based configuration and build system, for example), with
few minor exceptions.
The main reason has been that while python code is quick to slap together,
it has demonstrated a penchant for
Am Mi., 29. Sept. 2021 um 19:47 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:
> At a minimum, I think we should consider introducing Python on an optional
>>> basis (i.e., the C Kconfig implementation only gets used if a Python
>>> interpreter is unavailable), but making it required would be
Am Do., 30. Sept. 2021 um 15:22 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:
> IMO, any codebase is significantly easier and safer to maintain if there
> are tests.
>
Since we kinda-sorta support SPARK in our toolchain (not for the host
though at this time), maybe we should evaluate doing a
Am Do., 30. Sept. 2021 um 17:29 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:
> With respect to Kconfig, we (at Google) encountered a lovely build flake
> after the Kconfig uprev last month in the coreboot tree that took a couple
> of weeks to sort out and resolve. Some sort of automated
Hi Gregg,
Am Do., 30. Sept. 2021 um 21:16 Uhr schrieb Gregg Levine <
gregg.drw...@gmail.com>:
> fatal: unable to access 'https://review.coreboot.org/coreboot.git/':
> SSL certificate problem: certificate has expired
>
Given the timing, I wonder if
Am Mi., 29. Sept. 2021 um 16:43 Uhr schrieb Jack Rosenthal <
jrose...@google.com>:
> Overall I think introducing Python to the build would provide net benefit,
> mainly from Kconfiglib, but could also find other good uses in e2e tests
> like Ricardo was working on. Most people's Linux distros
Hi Selma,
Am Mo., 27. Sept. 2021 um 17:54 Uhr schrieb Bensaid, Selma <
selma.bens...@intel.com>:
> Here the build error, I checked that the error does not occurs with gcc 12
> revert. We are using Ubuntu 18.04 for our build nodes.
>
>
> src/drivers/bus/i2c/designware.c: In function
201 - 300 of 331 matches
Mail list logo
