This is another example of "don't try to support impossible hardware" :-)
The real bug is that coreboot build system let you build the i440fx with
APIC2, right? I assume that's what Paul meant.
OTOH, it is a way to test that linux properly fails when told to use
impossible hardware :-)
On Mon,
h for me to put 9 of 10
> > floppies of the collection described here (thanks to LZMA compression)
> > -
> http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Useful_floppies
> > , guess what wonders we can do with 31 MB... ;-)
> >
> > On Mon, Feb 19, 2024 at 7:17
Can the system you are discussing actually use larger than 16 MB rom?
I am wondering about your use of the phrase “out of curiosity”
On Mon, Feb 19, 2024 at 07:05 Mike Banon wrote:
> Small bump, I am still having this error while (out of curiosity)
> trying to build the Lenovo G505S ROM for
While it is true that there are binary blobs in coreboot today, that
was not always the case.
From 1999 to about 2011, all coreboot images were built from 100%
source code, most of it GPL, some of it BSD-style license (e.g.
microcode).
Around 2006, Intel made it impossible to continue with open
Were it not for the fact that we've been having the general open
source discussion with intel for 24 years, and this graphics
discussion for 10 years, we might believe that the claim of future
open source is possible.
Intel did not take open source into account when Intel wrote this
code; why
The approach in the last 24 years (of this unsustainable project :-) has
been to get several mainboards of a type, and, once we have them, try to
work out what code is truly common and what code is similar but not truly
common.
Code that is truly common can then be factored out into places such
There have always been two approaches to new mainboards in coreboot.
The first, "copy and convert", is to take the most similar board, copy the
code, and then change it. I believe this is the strategy paul is unhappy
with.
The second, "embrace and extend", is to modify existing board in place to
y.
>
> Am Sa., 1. Apr. 2023 um 18:07 Uhr schrieb ron minnich >:
>
>> https://review.coreboot.org/c/coreboot/+/74124
>>
>> First step, which I almost certainly did incorrectly, is to add Rust
>> toolchain support to the Makefile.
>>
>> Next, addi
https://review.coreboot.org/c/coreboot/+/74124
First step, which I almost certainly did incorrectly, is to add Rust
toolchain support to the Makefile.
Next, adding a rust payload was suggested. I'll look into that, probably
rewriting linuxcheck in rust (since I'm the only user anyway :-)
Ron,
>
>
> Am 08.01.23 um 20:16 schrieb ron minnich:
> > But in some cases static libs are no longer provided at all. Would be
> nice
> > to know if that's the case for libuuid.
>
> The static library is part of `uuid-dev` [1]:
>
> /usr/include/uuid/uuid.h
>
and I'll
>> supply images and instructions to get you up and running.
>>
>> Martin
>>
>> Jan 8, 2023, 12:16 by rminn...@gmail.com:
>>
>> > But in some cases static libs are no longer provided at all. Would be
>> nice to know if that's the case for libuuid.
>
But in some cases static libs are no longer provided at all. Would be nice
to know if that's the case for libuuid.
On Sun, Jan 8, 2023, 9:24 AM Nico Huber wrote:
> On 08.01.23 17:42, ron minnich wrote:
> > For reasons I still don't understand, the various linux distros no longer
If i look on ubuntu 18 I see this: /usr/lib/x86_64-linux-gnu/libuuid.a
If I look on ubuntu 22, it's no longer there.
to build firmware with this sort of library, you need the .a (which is for
static linking). Somewhat ironic, for UEFI, since the entire DXE model is
built on the DLL model, that
y
>>
>> https://universalscalablefirmware.groups.io/g/discussion
>>
>>
>>
>> What is USF? Links to USF training videos:
>> https://www.youtube.com/playlist?list=PLehYIRQs6PR5N73cbW8CPvU_stDTAG_j5
>>
>>
>>
>> Thanks,
>>
>>
note that I am having this exact same problem in the RISC-V community:
https://github.com/riscv-non-isa/riscv-sbi-doc/issues/102
People just like their SMM. It's hard to kill.
I fear that you're not going to get much luck with Intel, which is why I
try to work with non-Intel CPUs as much as I
gt; coreboot + edk2 firmware and install ChromeOS Flex, than to build
> their own ChromiumOS (vs ChromeOS, since the private overlays are not
> available) and manage updates
>
> On Mon, Sep 5, 2022 at 4:21 PM ron minnich wrote:
> >
> > I'm completely lost. Why would you update
I'm completely lost. Why would you update a chromebook to chromeos flex
when you can build chromeos and install that.
Did you know that you can build chromeos from source, rekey the chromebook,
and then it will boot in normal mode with your build? You can even run the
chromeos OTA service from a
Do we have criteria on which to decide if quark is worth keeping? Is
there a deadline for the work? At some point, you're going to find
code changing out from under you; are you committing to be the
maintainer?
On Tue, Jul 19, 2022 at 7:45 AM Angel Pons wrote:
>
> Hi Andy,
>
> On Tue, Jul 19,
I like it. We do this on most of my other projects.
On Thu, Jul 14, 2022, 6:12 AM Peter Stuge wrote:
> Patrick Georgi via coreboot wrote:
> > I was recently made aware that Gerrit now supports adding metadata to
> > commit messages in the "rebase" strategy.
>
> That's cool!
>
>
> > It's a
so how's it going?
On Tue, Apr 26, 2022 at 8:41 AM Martin Roth via coreboot
wrote:
>
> Thanks Andy, I think that's totally reasonable.
> Martin
>
> Apr 26, 2022, 06:56 by andy.p...@sdcsystems.com:
>
> > Felix wrote...
> >
> > >So, will you also step up as a maintainer for it?
> > I’m going to
They are incredibly useful, which is why they are still there. That
first post-bist code has been there since the first code in 1999.
If you have jtag, it still helps. But many BMC also have ways to see
port 80 writes. You can see it before PCI is up.
On Mon, Jul 11, 2022 at 8:00 AM Pedro
I've asked the software freedom conservancy to take a look.
On Wed, Jun 29, 2022, 2:48 PM Hal Martin wrote:
> Hello,
>
> Several Cisco Meraki products (MX84, MX250) are using the coreboot
> bootloader. Meraki are also distributing coreboot builds for these products
> via their update mechanism.
ese days it's sufficient to assume clang
> will catch any real problems (CB:62173).
>
>
>
> On Mon, May 16, 2022 at 1:03 PM ron minnich wrote:
>>
>> we have, in the past, used Linux kernel style as our guideline on
>> coreboot style.
>>
>> I'd say, based
come up.
On Mon, May 16, 2022 at 12:34 PM Martin Roth wrote:
>
> After reading what I've included below, I'm going to have to vote to keep the
> guards.
> Martin
>
> May 16, 2022, 10:59 by david.hendri...@gmail.com:
>
> > On Mon, May 16, 2022 at 8:59 AM ron minnic
good idea.
On Mon, May 16, 2022 at 9:59 AM David Hendricks
wrote:
>
> On Mon, May 16, 2022 at 8:59 AM ron minnich wrote:
> >
> > btw, sometimes this has gone the other direction ..
> > https://github.com/lowRISC/opentitan/pull/5693
>
> It looks like they did that s
btw, sometimes this has gone the other direction ..
https://github.com/lowRISC/opentitan/pull/5693
On Mon, May 16, 2022 at 3:04 AM Angel Pons wrote:
>
> Hi Arthur, list,
>
> On Sun, May 15, 2022 at 6:56 PM Arthur Heymans wrote:
> >
> > Hi
> >
> > To make sure headers don't create conflicts,
yeah, I ran out of time for now.
On Mon, May 2, 2022 at 10:57 AM Karl Semich <0xl...@gmail.com> wrote:
>
> I'm not working on this but am still interested in the idea, in my hobby
> capacity. The below emails were exchanged. I didn't yet receive further reply.
>
> -- Forwarded message
On Fri, Apr 22, 2022 at 11:59 PM Karl Semich <0xl...@gmail.com> wrote:
>>
>> We are deprecating ALL boards on oreboot that need FSP, as we took the
>> decision a few weeks ago to drop boards
>> that require blobs on the main CPU (we're accepting PSP blobs for now)
>
>
> Just a quick note that our
Nice job Werner, I'm completely shocked!
On Thu, Apr 21, 2022, 10:24 PM Zeh, Werner wrote:
> Hi everybody.
>
> It has been a while now that we started the open letter to Intel regarding
> open-sourcing the PSE firmware.
> I am now happy to announce that all this effort was not worthless!
>
oh oops the person doing that misunderstood me, we'll have to fix it
On Fri, Apr 22, 2022 at 5:41 PM Martin Roth wrote:
>
> Hey Ron,
> I think this is a good plan. We can make a markdown file doing the same.
> I'm not sure that coreboot wants to record where it's deleted, but instead
> the
we may be saying the same thing, but that commit in our file is the
"check this out to get this board" ref.
On Fri, Apr 22, 2022 at 5:41 PM Martin Roth wrote:
>
> Hey Ron,
> I think this is a good plan. We can make a markdown file doing the same.
> I'm not sure that coreboot wants to
The discussion here has been pretty helpful to my thinking. I think
the concerns people are raising are important.
We are deprecating ALL boards on oreboot that need FSP, as we took the
decision a few weeks ago to drop boards
that require blobs on the main CPU (we're accepting PSP blobs for now)
for a good example of matt's (1) above, see the pc engines apu2
coreboot image. It's very nice.
On Thu, Apr 21, 2022 at 7:05 AM Matt DeVillier wrote:
>
> there are two ways to handle multiple payloads in coreboot:
>
> 1) have a single primary payload, which provides the mechanism to
> execute
Arthur, your proposal would actually make things worse, surprisingly.
While your proposal would fix a problem, it would change the binary
layout, and create a problem.
Consider the case of a 10y old coreboot, with a modern kernel (Linux)
booting from it. How does linux parse the structures?
Wow, that one chip-specific kludge impacts almost 10 source files.
On Sun, Apr 17, 2022 at 11:15 AM ron minnich wrote:
>
> yes, and this is a perfect example of how one platform, which is not
> used, can cause unneeded features to persist and make the codebase
> more complex t
yes, and this is a perfect example of how one platform, which is not
used, can cause unneeded features to persist and make the codebase
more complex than it needs to be.
I support dropping it.
On Sun, Apr 17, 2022 at 2:12 AM Arthur Heymans wrote:
>
> Hi
>
> In 2016 'uart_pci_addr' was added to
to record mainboards we've dropped, with
their commit, so memory is not lost. Maybe with tags, maybe with plain
text file, not sure. It's possible whatever we try out will work for
coreboot, but we'll see.
On Sat, Apr 16, 2022 at 8:25 AM ron minnich wrote:
>
> nico, it was not so much a matter
nico, it was not so much a matter of me jumping on the bandwagon, as
my reluctance to get involved in another never-ending discussion over
retiring a platform that nobody uses or cares about.
But let's keep it simple. I think it's clear that the effort to
maintain the Quark is > 0. The number of
I think quark revival should come with a reasonable deadline. IOW, if
people are serious about keeping this platform, I think we ought to
see commitments as to when they report that it works. I'd suggest July
1. We've had a lot of commitments before, but everyone is busy, and
hopes can outrun
do you have a way to recover if the flash fails?
On Thu, Apr 14, 2022 at 1:09 PM Andy Pont wrote:
>
> Karl wrote…
>
> >Obviously a way to sidestep all this would be to simply test the board
> >in question, which is a small investment of money and time.
> There is still one of these boards (Intel
agree totally on how to lay out data
structures. UPD are also a major pain for non-C firmware, such as
oreboot.
So I'd like a data format that is not defined by a compiler or
language. But maybe I'm the only person who wants that :-)
On Tue, Apr 12, 2022 at 11:45 AM Peter Stuge wrote:
>
&g
peter, you are right about CBOR, and that says to me it does not
really meet the original goal of self-describing data. But coreboot
tables, at least in my understanding, is also not self-describing.
Do you have some thoughts on a good format that is self-describing?
On Mon, Apr 11, 2022 at 3:05
arthur, what might we do with either the build process or startup to
avoid this problem in future? Do you think we could find a way to
catch this programmatically soon, rather than humanly too late?
On Mon, Apr 11, 2022 at 2:48 AM Arthur Heymans wrote:
>
> Hi
>
> After last week's SMM loader
Does anyone even have one? Has anyone done a build and burn recently
to test? Has anyone volunteered to maintain it? How much does it it
impact other code as a special case?
I threw mine out years ago.
On Fri, Apr 1, 2022 at 6:19 AM Peter Stuge wrote:
>
> Felix Singer wrote:
> > to me it seems
go for it.
Long overdue.
On Thu, Mar 31, 2022 at 1:55 PM Felix Singer wrote:
>
> 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
he current U-Boot payload in coreboot supports UEFI.
> In the UEFI working group meeting there was a suggestion to take just
> the UEFI code from U-Boot and build our own payload for coreboot.
>
>
> On Sat, Mar 12, 2022 at 11:41 PM ron minnich wrote:
>>
>> so is your
so is your plan to port the UEFI code as a payload or to use u-boot
as a payload and then use their UEFI support?
On Sat, Mar 12, 2022 at 9:36 AM Ahamed Husni wrote:
>
> Hi everyone,
>
> On Fri, Feb 25, 2022 at 4:21 PM Ahamed Husni wrote:
> >
> > Dear All,
> >
> > I am hoping to apply for the
if these boards are to see maintenance in the future, so
> I figured it made sense to just start with that.
>
>
> On 5/12/21 5:53 am, ron minnich wrote:
> > 100 hours of work for 50 boards? 2 hours per board? Each one fully
> > tested and working as before? 'm pretty surprised.
ly buy a round of beer (or equivalent) for anyone who can provide a
> clear picture of what the road forward looks like. Then we can at least talk
> in grounded terms.
>
> -Matt
>
> On Wed, Dec 1, 2021 at 12:51 PM ron minnich wrote:
>>
>> We've always deprec
We've always deprecated platforms. And they're still in tree -- you
can build for DEC Alpha if you want. There's no shame in not being in
the latest release.
Given unlimited time and money and people, we could fix all the
problems. We live in a world of limits, and must do what we can with
the
having read this discussion, and with all respect for all the opinions
so clearly expressed, I still support Arthur's original proposal.
On Sun, Nov 28, 2021 at 2:20 PM David Hendricks
wrote:
>
>
>
>> 1. These boards will be gone for the people who check the "mainboards
>> supported by
The word 'drop' has ominous connotations, but it's not a deletion. A
board is never really gone. It's git. I can still find the Alpha
boards in there if I go back far enough. It's just that active
development ends, as no one is working to keep them up to date.
Would it be ok with you to drop the
I think, given how good a job you've all done with the release tags
and so on, it's easy for people to get to a working build for a board;
therefore, deprecating non conforming platforms make sense, as does
your suggestion for six months.
On Wed, Nov 24, 2021 at 4:51 AM Arthur Heymans wrote:
>
I'd like to get back to a rating system. There's a really simple
measure that I've never seen improved upon, namely, for a given
firmware image, what fraction of the bits in that image come from open
source code?
e.g., the KGPE-D16 would get a 100%, and a typical laptop would get 0%.
This is a
Still working on getting the setup, but 9elements reports: "We have it
running as CI System attached to a Github repo and do build and boot
testing on Qemu und real hardware with it."
On Sat, Oct 16, 2021 at 1:39 AM Patrick Georgi wrote:
>
> Am Sa., 16. Okt. 2021 um 02:40 Uhr sch
I would rather we not start depending on pytest. Just my take.There's
a difference between a utility for one chipset and global
infrastructure, and pytest could become the latter.
There's a pretty big testing activity starting up in OCP, involving
many companies, and python is not something we
;> Regards,
>> Patrick
>>
>> Am Mo., 4. Okt. 2021 um 18:59 Uhr schrieb Ricardo Quesada <
>> ricar...@google.com>:
>>
>>> Hi all,
>>>
>>> Regarding Patrick's 2nd point (end-to-end testing), what's the recommend
>>> way to go
i all,
>>
>> Regarding Patrick's 2nd point (end-to-end testing), what's the recommend way
>> to go forward?
>> I just need to run one of the Coreboot's utils (in this case "elogtool"),
>> and make sure the output is the expected one.
>>
>> Should I use Con
Stuge wrote:
>
> ron minnich wrote:
> > same applies to new software applied to antiques.
>
> While you are correct for some software and some antiques I find this
> premise completely unacceptable. This attitude may be convenient for
> developers but it only further normal
ums remain.
>
> On Tue, Oct 5, 2021 at 4:06 PM ron minnich wrote:
>>
>> That's what versions are all about. It seems sensible to me to leave
>> the old bad stuff behind; if people need it, it's all still there if
>> they know the tag.
>>
>> On Tue, Oct 5, 2
ere any more of these buggy pentiums left in the coreboot tree? (If he
> chooses to update) I can imagine RMS getting real snippy if we break his
> thinkpad. :P
>
> On Tue, Oct 5, 2021 at 3:53 PM ron minnich wrote:
>>
>> nice fine. Might be worth adding the text of this comment
nice fine. Might be worth adding the text of this comment (modified as
needed) to the CL so that in years to come people understand the
reasons.
On Tue, Oct 5, 2021 at 12:51 PM Matt B wrote:
>
> A quick google turned this up:
>
I would be happy if all those old buggy systems were gone, good idea Peter!
On Mon, Oct 4, 2021 at 9:39 AM Peter Stuge wrote:
>
> ron minnich wrote:
> > The problem, at this point, is that a change this broad must also be
> > tested across all platforms to make sure it's not b
Julian Stecklina
wrote:
>
> On Mon, 2021-10-04 at 07:32 -0700, ron minnich wrote:
> > that was pre-git but is there any useful comment in git anyway? I only
> > have the vaguest memory of why it went in.
>
> It was introduced in c84c1906b7 and fcd5ace00b3 without expla
use linuxboot, don't use UEFI payload. That's what we've done at
Google, among other companies (ByteDance too).
if you use linuxboot, then you get our pxeboot written in Go, and that
can use http to pull the image down as well as tftp; http is literally
(measured) 100x faster.
I would avoid
that was pre-git but is there any useful comment in git anyway? I only
have the vaguest memory of why it went in.
On Mon, Oct 4, 2021 at 7:14 AM Julian Stecklina
wrote:
>
> Hello,
>
> I was looking at the Local APIC code in coreboot and was wondering about
> `lapic_write_atomic` in
Speaking as the person who wrote the first few config tools in python,
and was happy to see the python dependency gone, I think bringing
python back in would be a mistake.
Every single python test framework I've worked with works until there
is a problem, and I then find myself having to walk
I think there are two issues here. First, we can't get it all right at
once. But, second, we have to think in terms of eventual scale. The
system will need to make the status of hundreds of motherboards
accessible.
The Google doc is wonderful for a deep dive, but a bit overwhelming as
the first
nice idea!
On Tue, Nov 10, 2020 at 7:13 AM Nico Huber wrote:
>
> On 10.11.20 16:06, Nico Huber wrote:
> > If anybody knows or discovers more cases where it needs to be enabled
> > in advance by coreboot, please mention it here.
>
> We just discussed on IRC cases where unfixable OS drivers might
Thanks for the note.
I think you're going at this somewhat backwards. While this may seem
to you to be a universal payload, to many it appears to be "make
everybody support UEFI model."
As you have seen, this will not be well received.
As Peter points out, the coreboot payload model is simple,
This is a welcome change, long overdue. It's not surprising there were
issues. It's far reaching enough that, if you had time, something in
Documentation detailing what you did and why could be very valuable
for future contributors?
ron
On Sat, May 16, 2020 at 12:30 PM Furquan Shaikh
wrote:
>
>
This one is not bad:
https://www.howtogeek.com/334013/intel-management-engine-explained-the-tiny-computer-inside-your-cpu/
overall, the ME could have been a neat idea, had it come without the
attendant security through obscurity.
it "coulda been a contenda"
ron
On Sat, Mar 14, 2020 at 4:45 PM
On Sun, Oct 13, 2019 at 6:42 AM Merlin Büge wrote:
>
> ... as far as I can see, u-bmc doesn't support the AST2050 yet (the BMC
> chip used by the KGPE-D16).
This is the kind of challenge people on this list live for :-)
The cool thing about u-bmc is that is has only about 1000 lines of
If you like running systemd on your bmc, the minimum 60 seconds
openbmc takes to boot, the complex, fragile, and long time it takes to
build from source, and the openbmc stack's need for giant memory
footprint and lots of nvme, stop reading.
IF, OTOH, you like the idea of a very lightweight
one thought just occured to me that might be useful.
We have a utility, called utk, that lets you script edits to UEFI
firmware volumes. I use it all the time to slice and dice and strip
these firmware volumes down. There are hundreds (500+) DXE in these
UEFI volumes that are not needed. I've
urce, eventually the code breaks and you
> enter the trivial case above.
>
>> "we must never remove source that is in use if the only replacement is a
>> blob"
>
> If the code works (it is in use after all), then refer to (1). Otherwise,
> this is the trivial c
Interesting discussion! It got me to wondering, having spent a lot of
time in the V1, V2, and V3 trees the last few months.
Is this statement true?
"There is no source so bad that a binary blob is better"
If we take that to be true, then what about this:
"bad source should never be replaced by a
> What about following proposal:
> coreboot is an extended firmware platform that delivers a lightning
> fast and secure boot experience on modern computers and embedded
> systems. As an Open Source project it aims to provide auditability and
> maximum control over technology; On some platforms
d Coreboot and UEFI background." If you have Coreboot
experience or know someone who is, see LinkedIn for contacting
Benyukhis."
I am convinced that things are getting better.
On Sun, Sep 1, 2019 at 7:38 PM ron minnich wrote:
>
> I should add that I support what Patrick is sayi
I should add that I support what Patrick is saying in this discussion.
I think he's right.
This is a good question to ask: "Can you point to even one instance in
the past few years where this strategy has yielded less vendor
proprietary firmware ..."
I think I can: I can point to the increasing
Just a note on oreboot: the name is taken, it means Rust, not C, and
you can see our talk about it next week. It works on SiFive HiFive-U.
We'd love to have help on real ARM chips.
We intend to be forceful about holding the line on "no development
from NDA data sheets", "no binary blobs", as well
On Tue, Jul 9, 2019 at 10:59 PM Frans Hendriks wrote:
> The COM board is 'subset' of mainboard.
> Suggestion is splitting COM board support (which is not a complete mainboard)
> from carrier support.
we had this type of board in LinuxBIOS v1 with some PPC systems and
followed a similar
On Tue, Jun 25, 2019 at 1:29 PM Julius Werner wrote:
> No we don't. We had a long discussion about multi-line comment styles
> some years back and I made the same argument there. ;)
you're totally right, oops! I misread the coding style again just a
few days ago. Sheesh!
>. I'd
> bet 95+% of
ould
> harm it. That's the same reason we write
>
> while {
>
> instead of
>
> while
> {
>
> like some other projects. (Of course blank lines can also help
> readability, but only in the *right* places and not randomly injected
> by style rules.) It would also move
Julius, good point. You're right.
I was about to talk to the author and ask if he would mind some help.
I'd like to see this code get in.
On Mon, Jun 24, 2019 at 5:28 PM Julius Werner wrote:
>
> > We're reviewing the STM code, of course.
>
> While we're on the topic, can someone please ask the
Thanks for clearing that up
On Mon, Jun 24, 2019, 11:16 AM Hubert Ruch wrote:
>
>
> On 6/24/19 10:17 PM, ron minnich wrote:
> > On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch wrote:
> >> Thanks for the info. Didn't know that. Now, one has to wonder how many
> skilled
> Well, I experience this very differently. Reviews aside, I spent most
> of my time with bug fixing. And most of the bugs I encounter are either
> due to unnecessary software complexity or because somebody ignored the
> little documentation that exists. Those aren't boot-coding problems.
re
On Mon, Jun 24, 2019 at 7:20 AM Hubert Ruch wrote:
> Thanks for the info. Didn't know that. Now, one has to wonder how many
> skilled developers actually do read and understand their code. IIRC Leah Rowe
> paid someone $90.000 for adding some code to LibreBoot. I'm mentioning this
> because it
On Thu, Jun 20, 2019 at 1:12 PM Stefan Reinauer
wrote:
>
>
>
> On 20 Jun 2019 08:26, ron minnich wrote:
>
> clang-format is not a textual preprocessor. It is basically the ast
> builder of followed by output.
>
> So in your case, I just tried it
> main() {
>
&g
this kind of
error. Constantly. I'm in favor of as much automation as we can get.
ron
On Thu, Jun 20, 2019 at 5:25 AM Nico Huber wrote:
>
> On 20.06.19 06:01, Jacob Garber wrote:
> > On Wed, Jun 19, 2019 at 08:38:14PM -0700, ron minnich wrote:
> >> Given the number of serio
Given the number of serious problems that lack of braces causes, I
like this proposal. It's indicative that both Rust and Go require the
{}, for reasons of safety.
On Wed, Jun 19, 2019 at 11:27 AM Jonathan Neuschäfer
wrote:
>
> On Wed, Jun 19, 2019 at 01:39:50PM -0400, Patrick Georgi via
if you boot windows 12 would you need tianocore?
On Mon, Jun 10, 2019 at 1:44 PM Nico Huber wrote:
>
> On 09.06.19 20:53, Matt B wrote:
> > It is possible through u-root support for multiboot images [1] to chainload
> > grub?
>
> Yes, I would think so. But in case we are still on topic: It won't
> On Sat, Apr 13, 2019 at 2:48 PM ron minnich wrote:
>>
>> Esxi works today freebsd is coming and windows is in Long term thinking
>>
>> On Fri, Apr 12, 2019, 11:46 AM Rafael Send
>> wrote:
>>>
>>> Good question, I'd be interested in
On Thu, May 23, 2019 at 6:13 PM Julius Werner wrote:
>
> > > * Can we adopt on principle removing all cpp guards on protos?
> > Why would this be a good idea?
> > What does "cpp guards" actually refer to?
>
> Upon re-reading this I *think* what they mean is stuff like
>
> #if CONFIG(SOME_OPTION)
to keep it
separate unless there is interest.
Possibly at the workshop in 2 weeks we can spend some time
establishing the proper way to code for oreboot.
Thanks
ron
On Mon, May 20, 2019 at 9:54 AM Jacob Garber wrote:
>
> On Fri, May 17, 2019 at 03:43:43PM -0700, ron minnich wrote:
> &
I need some gpio experts.
On an (e.g.) lewisburg, how does one enumerate the GPIOs and make them
visible in sysfs as one does on ARM? Is the info in ACPI in some magic
spot?
thanks
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send
Esxi works today freebsd is coming and windows is in Long term thinking
On Fri, Apr 12, 2019, 11:46 AM Rafael Send
wrote:
> Good question, I'd be interested in the answer to this as well if anyone
> has some insight.
>
> Cheers,
> R
>
> On Fri, Apr 12, 2019 at 7:45 AM Matt B wrote:
>
>>
yeah I agree. Thanks for responding Philipp, I dropped the ball.
We need to have another riscv hacking session in june.
On Thu, Apr 4, 2019 at 7:39 AM Philipp Hug wrote:
> Hi Xiang,
>
> I think the best way to integrate opensbi for now would be to put it into
> the payloads/external directory
I think extending ghidra is a great idea, and it is more than enough
for a gsoc.
On Fri, Mar 29, 2019 at 6:03 AM Daniel Lim wrote:
>
> Hi,
>
> I am Daniel, a computer engineering student at the National University
> of Singapore.
>
> I am interested in extending Ghidra to support the analysis of
The general usage pattern in Go is format-on-save-from-editor, unless
it's something like vscode where magic happens.
On Thu, Mar 28, 2019 at 2:03 PM Nico Huber wrote:
>
> On 16.03.19 18:15, Ron Minnich wrote:
> > On Sat, Mar 16, 2019 at 9:41 AM Patrick Georgi wrote:
> > o Hu
1 - 100 of 3036 matches
Mail list logo
