Doesn't -Wmisleading-indentation already catch all of this? That's
enabled by default on the coreboot gcc. I don't think "it's just a
heuristic" should be a concern unless anyone knows of a real example
that is otherwise valid coreboot code style but not caught by this
heuristic. (If we're worried
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
> We're reviewing the STM code, of course.
While we're on the topic, can someone please ask the NSA to honor our
coding style? ;) I don't want to get involved because it's really not
my area, but it looks pretty terrible at the moment (full of camelCase
and ALL_CAPS identifiers, C99 comments,
On Mon, 24 Jun 2019 08:17:14 -0700
ron minnich wrote:
> We're reviewing the STM code, of course. If you're going to worry
> about something, worry about FSP 2.0 still being closed source. FSP is
> not optional and we have no idea of all the things it does/can do.
Not only that.
For people that
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 developers actually do read
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
developers actually do read and understand their code. IIRC Leah Rowe paid
someone $90.000 for adding some code to
> 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 24.06.19 17:17, ron minnich wrote:
We're reviewing the STM code, of course. If you're going to worry
about something, worry about FSP 2.0 still being closed source. FSP is
not optional and we have no idea of all the things it does/can do.
You are saying this as if it would be magically
On 23.06.19 12:04, Hubert Ruch wrote:
On 6/23/19 12:00 PM, Stefan Reinauer via coreboot wrote:
Remember that the project was started by Los Alamos National Labs
(LANL), the guys that also brought you the Manhattan Project.
Contributions have also been made by the BSI (German version of the
NSA)
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 22 Jun 2019 21:30, Anac wrote:
Dear all,
Is it true that there's code provided by the NSA implemented in
Coreboot?
https://www.tomshardware.com/news/nsa-contributes-low-level-stm-coreboot,39704.html
Any thoughts?
Cheers
On 6/23/19 12:00 PM, Stefan
A new post titled "[GSoC] Debug Bootblock Stage for ARMv8 on QEMU" has been published on the coreboot blog. Find the full post at https://blogs.coreboot.org/blog/2019/06/24/gsoc-debug-bootblock-stage-for-armv8-on-qemu/
Hello again, I’m Asami. I’ve just finished 4 weeks as a GSoC student. I’m
I planned to test coreboot on this board as well, and I'm having the same
problem (compiled from latest source).
The sticks I currently have are 16GB VLP ones. I've some M392B2G70DM0-YK0, and
a few HMT42GR7AFR4A-PB. None worked with this board using coreboot, giving out
similar "DIMM training
13 matches
Mail list logo
