On Wed, Feb 18, 2015 at 10:49 AM, Alexandru Gagniuc
mr.nuke...@gmail.com wrote:
On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote:
As I have noted on http://review.coreboot.org/#/c/7924/ it's very
short sighted to go this route. In assembling a coreboot stack (which
includes
On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc
mr.nuke...@gmail.com wrote:
On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote:
You still haven't made any counter-argument to the practicalness of being
compatible with the software systems where coreboot gets contribution.
And
2015-02-18 18:35 GMT+01:00 Aaron Durbin via coreboot coreboot@coreboot.org:
coreboot is different than:
1. linux
2. uboot
And similar to Solaris, Windows and the BSDs.
As for libpayload, I'd rather import code from BSD than Linux for
licensing reasons.
3. libpayload
4. Anything using
On Wednesday, February 18, 2015 04:41:13 PM ron minnich wrote:
Having spent 15 or so years on Plan 9 and Linux, the only conclusion I can
make is that nothing is universal.
Plan 9 is this:
outl(int port, ulong value)
Finally an implementation that makes sense. Those out[lbw]() accessors
Well, I say it again: it matters not. I don't care how we do it, some ox is
going to get gored.
The order is much less important than consistency. And ox are tasty. So
let's gore one.
The problem for me is not that I have an opinion, but that people I
respect so highly have
different opinions.
On Wednesday, February 18, 2015 11:50:04 AM Aaron Durbin wrote:
On Wed, Feb 18, 2015 at 11:41 AM, Alexandru Gagniuc
And you still haven't responded to my proposal of using EFI style.
I thought that was a non-sensical proposal.
My point exactly.
Alex
--
coreboot mailing list:
On Wednesday, February 18, 2015 08:23:08 AM Vadim Bendebury wrote:
On Wed, Feb 18, 2015 at 7:16 AM, Aaron Durbin via coreboot
As I have noted on http://review.coreboot.org/#/c/7924/ it's very
short sighted to go this route. In assembling a coreboot stack (which
includes libpayload and the
On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote:
As I have noted on http://review.coreboot.org/#/c/7924/ it's very
short sighted to go this route. In assembling a coreboot stack (which
includes libpayload and the payload itself) the code usually comes
from different software
On Wednesday, February 18, 2015 11:35:13 AM Aaron Durbin wrote:
You still haven't made any counter-argument to the practicalness of being
compatible with the software systems where coreboot gets contribution.
And you still haven't responded to my proposal of using EFI style.
Alex
--
On Wednesday, February 18, 2015 05:14:15 PM ron minnich wrote:
Somebody make a decision and go for it. Just make sure it's type safe so we
can catch it when I get it backwards.
write[8|16|32|64](void *addr, uint[8|16|32|64]_t val);
There. It's done :)
Sorry I have been absent, somehow I got
Once the order is the same on all architectures, we could change it
to match Linux at any point. I think its important to stop holding
up architectural unification in the name of the perfect solution.
The Coccinelle to switch the ordering is much safer to do after you have
the ordering consistent
On 02/18/2015 12:52 PM, Julius Werner wrote:
FWIW I sightly prefer write32(a, v)
Then go for it.
Alex
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
As Patrick already said, compared to the total effort to integrate external
sources, the issue of argument order is insignificant. In the time you spent
writing this email, you could have found out how to do it with coccinelle,
and
could have applied it to any number of sources.
The 1.8.0 version of SeaBIOS has now been released. For more
information on the release, please see:
http://seabios.org/Releases
New in this release:
* Several USB timing fixes for USB controllers on real hardware
* Initial support for USB3 hubs
* Initial support for SD cards (on QEMU only)
*
* Julius Werner jwer...@chromium.org [150218 00:12]:
I'd like to propose an API change/cleanup for a long-standing problem
with architecture-independent code that people have hit and privately
discussed/cursed multiple times already, but no one really had time to
make the big change/fix yet.
On Wed, Feb 18, 2015 at 8:49 AM, Alexandru Gagniuc mr.nuke...@gmail.com
wrote:
On Wednesday, February 18, 2015 09:16:07 AM Aaron Durbin wrote:
As I have noted on http://review.coreboot.org/#/c/7924/ it's very
short sighted to go this route. In assembling a coreboot stack (which
includes
* Timothy Pearson tpear...@raptorengineeringinc.com [150205 19:23]:
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f]
On Wednesday, February 18, 2015 10:21:44 PM Stefan Reinauer wrote:
* Alexandru Gagniuc mr.nuke...@gmail.com [150214 02:14]:
[..]
Do we really want to push people's nerves every year until we finally get
a
fork?
Alex
Alex,
the leadership of this project reserves the right to
On Wed, Feb 18, 2015 at 10:52 AM, Julius Werner jwer...@chromium.org
wrote:
As Patrick already said, compared to the total effort to integrate
external
sources, the issue of argument order is insignificant. In the time you
spent
writing this email, you could have found out how to do it
* Alexandru Gagniuc mr.nuke...@gmail.com [150214 02:14]:
It's that time of the year it seems. Last year, there were talks about
reducing the number of gerrit submitters. I'm certain you remember the anger
this caused amongst non-commercial members of the community when the proposed
list
* Alexandru Gagniuc mr.nuke...@gmail.com [150214 01:13]:
On Saturday, February 14, 2015 12:05:28 AM Marc Jones wrote:
Hi Everyone,
Hi,
Please update the wiki page with project ideas.
http://www.coreboot.org/Project_Ideas
That's the first unlocked page in the coreboot wiki I have
Hi all.
I am fully aware of how I2C bus works and I never liked this interface. This is
because you cannot really probe devices on the bus, there is not really a
status information available on the bus and one can confuse a slave in that way
that it will block the bus without a way to reset it
On Wed, Feb 18, 2015 at 7:16 AM, Aaron Durbin via coreboot
coreboot@coreboot.org wrote:
On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc
As I have noted on http://review.coreboot.org/#/c/7924/ it's very
short sighted to go this route. In assembling a coreboot stack (which
includes
On Wed, Feb 18, 2015 at 9:16 AM, Aaron Durbin adur...@google.com wrote:
On Tue, Feb 17, 2015 at 10:44 PM, Alexandru Gagniuc
mr.nuke...@gmail.com wrote:
On Tuesday, February 17, 2015 04:32:18 PM Julius Werner wrote:
The x86 was recently fixed to take in void *. The order of arguments was
2015-02-18 17:23 GMT+01:00 Vadim Bendebury vben...@chromium.org:
kernel, u-boot, etc. They all have the write(val, addr) semantics. I
see no good reason to artificially erect an ever present barrier for
integrating code into a coreboot system.
Since all imported code requires some rework
On Wed, Feb 18, 2015 at 10:35 AM, Patrick Georgi pgeo...@google.com wrote:
2015-02-18 17:23 GMT+01:00 Vadim Bendebury vben...@chromium.org:
kernel, u-boot, etc. They all have the write(val, addr) semantics. I
see no good reason to artificially erect an ever present barrier for
integrating code
Having spent 15 or so years on Plan 9 and Linux, the only conclusion I can
make is that nothing is universal.
Plan 9 is this:
outl(int port, ulong value)
And I used software that came long before Linux (back in the 70s, if you
want to know) that followed that form too. I think Linux got it
I think nobody disagrees that type checking is a bad idea here.
I ain't not unsure that you failed to not make no mistake with the
missing lack of double negatives there... ;)
I don't think this argument makes sense for code that is being actively
developed in other code bases and imported
Hello!
Here's suggestion.
Let's drop the whole business. Its taking over from the regular day to
day business.
-
Gregg C Levine gregg.drw...@gmail.com
This signature fought the Time Wars, time and again.
On Wed, Feb 18, 2015 at 4:48 PM, Alexandru Gagniuc mr.nuke...@gmail.com wrote:
On
Hi,
I am currently planning to set up a test system with 5 (later up to 10)
machines boot testing each new coreboot commit. This test system will be
serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST office hours.
Current goals for every commit:
- Check if coreboot + SeaBIOS are able
2015-02-19 0:14 GMT+01:00 Carl-Daniel Hailfinger
c-d.hailfinger.devel.2...@gmx.net:
Hi,
I am currently planning to set up a test system with 5 (later up to 10)
machines boot testing each new coreboot commit. This test system will be
serviced (i.e. recovery from bricking) Mo-Fr during CET/CEST
On Wed, Feb 18, 2015 at 2:47 PM, Julius Werner jwer...@chromium.org wrote:
I think nobody disagrees that type checking is a bad idea here.
I ain't not unsure that you failed to not make no mistake with the
missing lack of double negatives there... ;)
I don't think this argument makes
32 matches
Mail list logo
