libpayload uses both.
For example, line 52 defines a class "libcbfs", line 64 adds the subdir
"libcbfs".And
https://elixir.bootlin.com/coreboot/latest/source/payloads/libpayload/libcbfs/Makefile.inc
adds its sources to the libcbfs class.
Roughly speaking: subdirs-y just makes the build system
29. November 2023 12:14, "Poeche, Uwe via coreboot"
schrieb:
> Your above mentioned patch helps (I'm a reviewer of this). When I tried I
> also noticed that this
> does not point out loudly if you have problems in your config. So the
> approach without the patch
> (in result more strict) is
On 29.11.23 00:20, Martin Roth via coreboot wrote:
Hey Mike,
I think you should be able to just append change the kconfig values when you
run make to override the current settings.
something like
`make menuconfig KCONFIG_WERROR=0 KCONFIG_WARN_UNKNOWN_SYMBOLS=0`
if we update where they're set
On 28.11.23 19:04, Mike Banon wrote:
Are there any advantages of KCONFIG_STRICT / KCONFIG_WERROR that
outweigh these potential issues?
It ensures that we don't silently build with unknown symbols (typo in manual
editing, changes to the config, ...), and wonder why CONFIG_UART_DEBUG=y
doesn't
Hi everybody,
I updated Kconfig to track latest Linux last week and that brought some
behavioral change with it. While these changes are appreciated in some respect,
they also complicate work in others.
I now proposed https://review.coreboot.org/79298, a change that exempts _all_
*config
Am 26.11.2023 um 18:15 schrieb Mike Banon:
/usr/bin/ld: build/util/kconfig/lxdialog/yesno.o: warning: relocation
against `acs_map' in read-only section `.text'
/usr/bin/ld: build/util/kconfig/mconf.o: in function `show_help':
mconf.c:(.text+0x1770): undefined reference to `stdscr'
/usr/bin/ld:
12. September 2023 17:59, "Felix Singer" schrieb:
> 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?
I
Am 06.09.2023 um 18:57 schrieb Williams, Hannah:
Here are the reasons why we cannot open source Meteor Lake uGOP:
- It has licensed code for HDMI and other industry specifications (i915 also
cannot open source HDMI 2.1)
- VBT spec is not open sourced
There will have to be a re-design of the
Am 27.08.2023 um 19:18 schrieb Tim Wawrzynczak:
Also, to be perfectly honest, I don't understand why this "sign-of-life"
feature is so critical that it must be available during development.
When I (and a few others) came up with the idea at Google, the entire
point of the feature is so that
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
"Angel Pons" schrieb:
> We made the patches that made Coverity angry about this `format_pn()`
> function. However, this is not an actual bug: the
> `eeprom_read_serial()` function returns a buffer that is at most 32
> (`HERMES_SN_PN_LENGTH`) characters long, and the length of the
> `prefix`
Am 02.09.2022 um 03:38 schrieb Julius Werner:
Right now, when you have a CL that builds fine but fails unit tests,
Jenkins with Verified -1 it with a failure page like this
https://qa.coreboot.org/job/coreboot-gerrit/215770/ , which just says
"Test Result (no failures)". If you know your way
Hi everybody,
22. Juli 2022 16:56, "Patrick Georgi via coreboot"
schrieb:
> On August 1, I'll change the coreboot repo to use that submission strategy
> and then we'll have a
> month to see how it works for us. Late August we can make a decision whether
> to sta
Hi again,
On 2022-07-13 I wrote:
> David proposed that we could try out "rebase always" for a while (maybe a
> month) to see how it
> feels.
This idea has been positively received on the list and nobody voiced objection
to such a change.
As a server admin I declare that August will be
Hi everybody,
I was recently made aware that Gerrit now supports adding metadata to
commit messages in the "rebase" strategy. The "cherry-pick" strategy that
we're using has been chosen over everything else primarily due to this
capability.
Some details:
Gerrit supports different ways of
Am 12.04.2022 um 23:54 schrieb Karl Semich:
Obviously a way to sidestep all this would be to simply test the board
in question, which is a small investment of money and time.
I appreciate that you volunteer to do that for Quark. Can't be too bad,
it's a small investment of money and time, after
Might be interesting for a few folks here?
-- Forwarded message -
Von: Richard Hughes
Date: Di., 25. Jan. 2022 um 12:20 Uhr
Subject: [Lvfs-announce] LVFS Community Meeting: Alternate Branches
To:
Hi all,
We normally only allow the silicon vendor, the ODM or the OEM to
upload
Hi Jay,
from your description I'm not clear what you added to your root certificate
store.
Let's Encrypt provides their root certs in various formats at
https://letsencrypt.org/certificates/
Things should work after you add those (right now, review.coreboot.org is
certified through the X1 root)
1. Dezember 2021 12:06, "Paul Menzel" schrieb:
> If I remember correctly, coreboot’s goal to only do minimal hardware
> initialization originally meant, that the payload/OS does PCI
> initialization.
The original idea was to boot into Linux (hence LinuxBIOS, back in the day).
coreboot is very
Am 28.11.2021 um 02:44 schrieb Peter Stuge:
Patrick Georgi via coreboot wrote:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of
deprecation plans,
I think the difference is unimportantly subtle
24. November 2021 21:16, "Mike Banon" schrieb:
> With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of
deprecation plans, but since deprecations have been interpreted like that too
often, I propose using clearer
Am 25.11.2021 um 18:06 schrieb AreYouLoco? via coreboot:
In my opinion coreboot is more developer friendly than user friendly.
Kinda obvious: We don't even ship binaries...
Given the trouble these deprecation announcements always are, I can tell
you an even more developer friendly strategy:
On 25.11.21 17:04, Mike Banon wrote:
2. It's not just the loss of boards - it's also the loss of coreboot
users/contributors who only have these boards and don't want to switch
These users didn't contribute fixes to their boards (or even just feedback that
things needs to be done and testing
12. November 2021 20:35, "Felix Singer" schrieb:
> 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?
I was thinking about renaming the feature "hide from UI" or something like
Since this appears to be blowing up (because we didn't have enough crap this
week already, right?), let me respond a bit longer to the list for completeness
sake:
12. November 2021 11:05, "Keith Emery" schrieb:
> But would anyone else like to explain why this isn't a GPL violation? Because
>
Hi everybody,
it came to my attention that changes marked "private" on Gerrit are hidden in
the UI but easily accessible through gitiles and with "git fetch".
I don't think it matters for most cases, but since we advertised it as being
accessible for the owner and individual reviewers, I
Dear coreboot project,
this discussion heated up and escalated considerably, to the point where things
got personal.
I have since put Nico and Martin into temporary moderation for this mailing
list, in an attempt to get the temperature down at least within the project.
The timing of me doing
Hi Julian,
November 9, 2021 6:27 PM, "Julian Stecklina"
wrote:
> This works, but I wonder whether this is the intended way to use Coreboot or
> whether there is some more elaborate way to do it. Does all of Coreboot have
> to
> be mapped at the end of 4G? Or is there any documentation on
Am So., 7. Nov. 2021 um 12:29 Uhr schrieb Nico Huber :
> There's also a general reluctance to expect to support a project with
> free software that has shown that it doesn't take the GPL seriously.
>
General reluctance by whom? I just don't see that, instead I see tons of
activity by a very
Am Fr., 5. Nov. 2021 um 19:11 Uhr schrieb ron minnich :
> e.g., the KGPE-D16 would get a 100%
>
except for the VGABIOS.
> Marketing types are sensitive to numbers like this: we could
> prominently display these numbers on coreboot.org
>
They're also pretty sensitive about any kind of mistake
Am Fr., 5. Nov. 2021 um 18:16 Uhr schrieb Martin Roth via coreboot <
coreboot@coreboot.org>:
> The current reality is that binary blobs are needed for almost every
> platform in coreboot. I believe the coreboot leadership is united behind
> the unfortunate reality that allowing these blobs is a
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 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
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 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 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,
> 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 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 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
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 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 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 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
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
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 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
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
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.
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
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.
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
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,
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 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
&
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 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
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
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
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
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 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 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 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
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 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 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 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
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
--
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.
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
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 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 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 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 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 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
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 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
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 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
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
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,
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
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
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
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 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 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., 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
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
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
1 - 100 of 331 matches
Mail list logo
