On Friday, July 17, 2015 03:32:43 PM Aaron Durbin wrote:
On Fri, Jul 17, 2015 at 3:27 PM, ron minnich rminn...@gmail.com wrote:
bummer. We're going to have to add marshalling code to cbfs, to copy
Ya. You'd need to fix cbfs as well is my guess.
Not really. It's OK to be extra careful when
On Monday, April 13, 2015 05:07:18 PM Peter Stuge wrote:
pub...@autistici.org wrote:
Can support be added for Hewlett-Packard's Pavilion dv7-6025eo laptop
computer? Details:
Probably yes, but nobody will do it for you.
You're making some implicit assumptions here. Of course someone else will
On Thursday, March 26, 2015 07:44:24 PM Łukasz Dmitrowski wrote:
Hello,
Hi
To provide easy and clear interface for end user flash
tool(http://www.coreboot.org/Project_Ideas#End_user_flash_tool) I plan
to implement GUI with use of Qt framework. I decided to go with Qt
I think Qt is a very
On Thursday, March 26, 2015 07:43:26 AM Kushagra Kumar wrote:
Which is the best Linux based os to be worked on with coreboot?
Fedora
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Thursday, March 12, 2015 07:29:00 PM Peter Stuge wrote:
Stefan Reinauer wrote:
I would like to organize a coreboot project meeting in San Jose,
California this summer.
..
If you are interested in joining this summer, if you have ideas, or
concerns, please contact me
Chances are
So, as I was iotracing atombios execution from within linux. The hardware
connection is pretty straightforward: AMD Trinity DP0 - RTD2132 - LVDS
panel. I noticed a set of very interesting DPCD accesses [1], to registers
marked as RESERVED for Branch device usage by the Display Port spec.
So I was looking at our git log. I can fit two, maybe three commits if I'm
lucky. It's terrible. We have all this redundant information. We have both
Reviewed-on and Change-Id lines. Those only point to the same resource.
The Tested-by is useless. It's always Jenkins who tests changes. Then you
I want to convert a replay log to something that looks more structured, and
easier to parse through mentally. I've tried to use coccinelle, but I came
across a couple of problems. First, the file is over 13000 (thirteen thousand)
lines long, and coccinelle crashes with a stack overflow error
On Monday, April 21, 2014 09:24:57 AM ron minnich wrote:
Oh, wait, what mailing list is this again? I thought it was the ~coreboot
list.
I thought Chromebooks were very on-topic, or did we drop them from our tree?
Alex
--
coreboot mailing list: coreboot@coreboot.org
On Monday, April 21, 2014 10:05:40 AM ron minnich wrote:
coreboot on chromebooks are very on topic. Track pad drivers for
Linux, or the trackpad firmware, or the trackpad vendor, or the
algorithms used, or the fact that you made this comment in such a way
that nobody from the trackpad group
To manufacturers of Chromebooks,
Sorry guys, I have a chromebook myself, and its touchpad is appalling. I've
also tried the chromebooks in stores and they aren't much better.
But have no fear, Alex is here, and has the perfect recipe on how to squash
such hardware bugs early on. Following
On Thursday, April 17, 2014 12:41:39 PM ron minnich wrote:
Paul, very nice, thanks. It's not real surprising, actually, at least
in my old scientific computing world.
Since that is AMD code, maybe we can get the guys who wrote it to read
that nice book written by AMD :-)
OUCH! Right under
On Tuesday, April 08, 2014 08:32:46 AM Duncan Laurie wrote:
If we do go the route of having lots of mainboard handlers I think we
should keep the method names consistent with the ACPI spec and use a
mainboard namespace to separate them. Conditional references are
already a headache in ASL and
For those of you with Trinity CPUs, coreboot, and working S3 resume, is it
necessary to run the VGA option ROM on S3 resume to get video back? Which
output are you using (VGA, DP, etc) ?
Alex
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Installing coreboot can be an either enthralling or appalling experience. If
you're new to coreboot and want to give it a try, following a few simple steps
can save you a ton of time and frustration.
Ask around first
Let the coreboot people know you want to try coreboot on
OK, I've started a page [1] where ideas can go. Once we stabilize the spec,
I'll remove the warning on top, and we can consider that to be policy.
[1] http://www.coreboot.org/ACPI/Board-EC_interaction
--
coreboot mailing list: coreboot@coreboot.org
On Monday, April 07, 2014 04:55:05 PM Peter Stuge wrote:
mrnuke wrote:
Turns out that I needed to tell the EC to go into ACPI mode, as it boots
up in APM mode.
Blame MS-DOS and the 1990s.
Damn you MS-DOS and the 1990s!!!
Signed,
A disgruntled hardware hacker
--
coreboot mailing list
This is an ugly one, and we keep having to find different workarounds to make
this happen. We have the preprocessor, so why not use it?
Define a set of common ACPI method names which the mainboard code should
define, and the EC code can always use.
* MB_TOGGLE_WLAN() or MB_TOGGLE_WIRELESS()
It's changing the ROM base (devfn 14.3, register 0x6c) from 0xffc0 to 0xff00.
The bootblock sets it up correctly, but AmdInitReset messes it up.
Any ideas? AGESA is particularly annoying to grep.
Alex
--
coreboot mailing list: coreboot@coreboot.org
On Sunday, April 06, 2014 05:16:53 PM Scott Duplichan wrote:
mrnuke [mailto:mr.nuke...@gmail.com] wrote:
]It's changing the ROM base (devfn 14.3, register 0x6c) from 0xffc0 to
0xff00. ]The bootblock sets it up correctly, but AmdInitReset messes it up.
]
]Any ideas? AGESA is particularly
On Saturday, April 05, 2014 03:34:22 PM mrnuke wrote:
My guess is that vendor BIOS handles SMI and then somehow triggers SCI in
software. I'd try to route all GPE to SCI.
Turns out that I needed to tell the EC to go into ACPI mode, as it boots up in
APM mode. In APM mode, it causes SMIs
So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC
running as expected. It seems that, at least the (ACPI) register layout is the
same. We can get good battery _and_ AC indicators from it.
When we query the EC (say, doing a cat /sys/class/power/AC/online), it
So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC
running as expected. It seems that, at least the (ACPI) register layout is the
same. We can get good battery _and_ AC indicators from it.
When we query the EC (say, doing a cat /sys/class/power/AC/online), it
On Saturday, April 05, 2014 08:21:21 PM Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 05.04.2014 19:02, mrnuke wrote:
When an event happens, on the other hand, like a hotkey, or AC is removed,
it does not generate an SCI that would lead to a query call (_Qxx).
Instead it spits out an SMI
On Friday, April 04, 2014 10:00:41 AM ron minnich wrote:
I have this nice board, with a nice AMD cpu, and I get no graphics.
Why? Because AMD won't release the VGA blob. So the board is headless.
Are you talking about a board which originally came with IBV firmware? In that
case, you may be
On Friday, April 04, 2014 11:08:29 AM ron minnich wrote:
Now, there's no need to be that mean, ok? AMD are not bad guys in my
view. But they have made some seriously boneheaded decisions, and
locking up the VGA bios is one of them.
Not mean, disappointed.
We can't get anywhere calling
Let's think of a few things which makes gerrit annoying:
* -2 is a de-facto veto
* -1 is not persistent on updates, encouraging -2 to be given
The end result is that we're encouraging vetoing of patches.
Proposal:
* Submitability of a patch is based on overall review score
** Need at least a
On Wednesday, April 02, 2014 08:41:10 AM ron minnich wrote:
This license still looks problematical to me. Couple that with the
fact that the Haswell MRC is still not generally available from Intel
and I'm a bit concerned.
If I build a coreboot image with FSP, am I allowed to put it on
On Wednesday, April 02, 2014 10:08:37 AM ron minnich wrote:
On Wed, Apr 2, 2014 at 9:38 AM, mrnuke mr.nuke...@gmail.com wrote:
That is a clear attempt to circumvent the
wishes of the rightsholders to this project.
That part I believe you are missing here is that this is a balancing
On Wednesday, April 02, 2014 12:15:35 PM mrnuke wrote:
On Wednesday, April 02, 2014 10:08:37 AM ron minnich wrote:
On Wed, Apr 2, 2014 at 9:38 AM, mrnuke mr.nuke...@gmail.com wrote:
That is a clear attempt to circumvent the
wishes of the rightsholders to this project.
That part I
On Wednesday, April 02, 2014 10:17:13 AM ron minnich wrote:
On Wed, Apr 2, 2014 at 10:15 AM, mrnuke mr.nuke...@gmail.com wrote:
$ git grep -i intel |grep -i copyright |grep -v microcode
Point being?
I talk about Intel and their attempt to circumvent the wishes of the
rightsholders. You
On Wednesday, April 02, 2014 10:25:39 AM ron minnich wrote:
On Wed, Apr 2, 2014 at 10:17 AM, David Hubbard
david.c.hubbard+coreb...@gmail.com wrote:
Could the two interested parties negotiate a compromise? In my mind that's
Google calling Intel, and they talk it over. That probably just
Paul, please ignore my top-posting. Could you please not hijack threads as
long and tedious as this one? Feel free to quote the comments you are
referring to, but make sure to scrub the in-reply-to field. It's getting
tedious to read this.
Oh, and probably a lot of people have muted this
On Friday, March 28, 2014 10:03:28 AM Paul Menzel wrote:
Dear coreboot folks,
Alexandru put wood behind the arrow to get coreboot running on an AMD
based laptop. He took his old HP Pavilion m6-1035dx [1] and in a
day/night had coreboot running on it and he submitted the patch set for
On Wednesday, March 26, 2014 09:13:38 AM Björn Busse wrote:
Now I did it, hijacked this thread (Hi mrnuke!).
TL;DR. You're doing it wrong.
Alex
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Not so long ago, Stefan announced some pretty drastic changes to the project
structure. While I believe he wanted to discuss the direction and find a
mutually agreeable direction, his email still raised the aneurysm level to
over nine thousand.
So, how about we take the good ideas out of there
On Wednesday, March 26, 2014 03:32:12 PM Patrick Georgi wrote:
Am Mittwoch, den 26.03.2014, 09:22 -0500 schrieb mrnuke:
Masters, of Gerrit, the pleasure of training gerrit to implement this
change is left entirely to you.
While we're specifying behaviour: what should happen to changes
In the search for a good LTS (long term support) laptop, I've had to think
hard of which blobs could be consider acceptable, and which would disqualify
candidates. I've made a write-up about this classification here[1].
The idea is simple: find out which blobs would disqualify the machine from
I should delete my reply button. Darn! It's reply to all.
Sorry Ron.
On Wednesday, March 26, 2014 03:05:47 PM mrnuke wrote:
On Wednesday, March 26, 2014 01:01:10 PM you wrote:
Ah, that's what I meant by persistent. Let's take your name and get
rid of mine, and we're still at 2 axes
On Monday, March 24, 2014 10:31:49 PM ron minnich wrote:
On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke...@gmail.com wrote:
* For example, a hardwired boot blob which has been RE'd so that we know
what it does and how it does it, would be acceptable (see Allwinner).
Hard for me to agree
On Monday, March 24, 2014 10:36:27 PM David Hendricks wrote:
On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke...@gmail.com wrote:
Chose the hardware. Set up a github temporary fork. Send me the hardware.
I got Pomona, I got SPI, I got USB debug, and I got the burning desire to
make
On Tuesday, March 25, 2014 10:53:51 AM ron minnich wrote:
Just one thing. Don't underestimate just how miserable the EC can make your
life. I place a high premium on systems
with an open EC. Just be careful there.
Can you tell us more about the Samsung Chromebook 2?
Alex
--
coreboot
On Tuesday, March 25, 2014 06:56:13 PM Stefan Reinauer wrote:
* ron minnich rminn...@gmail.com [140325 06:34]:
On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko
phco...@gmail.com wrote:
I don't see how this prevents any of my propositions for the bulk of
On Tuesday, March 25, 2014 07:51:33 PM Stefan Reinauer wrote:
* mrnuke mr.nuke...@gmail.com [140325 08:37]:
a branch containing that hash is not available publicly.
Baloney. Your not finding it does not mean it's not available. It means
you didn't look hard enough.
I call
On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote:
On Tue, Mar 25, 2014 at 10:57 AM, mrnuke mr.nuke...@gmail.com wrote:
On Tuesday, March 25, 2014 10:53:51 AM ron minnich wrote:
Just one thing. Don't underestimate just how miserable the EC can make
your life. I place a high
On Tuesday, March 25, 2014 02:14:12 PM ron minnich wrote:
On Tue, Mar 25, 2014 at 1:26 PM, David Hendricks dhend...@google.comwrote:
On Tue, Mar 25, 2014 at 12:17 PM, mrnuke mr.nuke...@gmail.com wrote:
On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote:
On Tue, Mar 25, 2014 at 10
On Monday, March 24, 2014 05:00:26 PM ron minnich wrote:
I keep wanting to drop out of this discussion but there are some things I
just can't let go by,
Let's focus on constructicism then (if that is even a word).
On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel
On Sunday, March 23, 2014 07:34:32 AM Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
On 23.03.2014 04:10, Peter Stuge wrote:
That isn't too different from creating a fork?
Fork is better. With fork we don't have to deal with the same people who
pushed the community out in the first place.
On Sunday, March 23, 2014 05:37:37 PM Peter Stuge wrote:
David Hubbard wrote:
But Peter, what's your take on Alex's suggestion: What do we need to
do to allow commercial contributors to work directly upstream? And
before you discount this question for menial technical reasons,
please take
On Friday, March 21, 2014 09:18:07 PM ron minnich wrote:
On Fri, Mar 21, 2014 at 6:52 PM, Alex G. mr.nuke...@gmail.com wrote:
The bad-ness or good-ness of motives is relative. Note that I'm not
using bad in the sense of evil. Let's look at the six gatekeeper idea:
* Easier for
On Friday, March 21, 2014 11:19:42 PM ron minnich wrote:
If you're going to make big changes to what happens at coreboot.org,
you have to get buyin from the folks who do all the work.
If we're going to refactor the development model, I insist we do it right.
Patrick was discussing gitlab as
On Saturday, March 22, 2014 03:56:46 AM Andrew Wu wrote:
Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem
if without romcc. :(
Is there any way whatsoever to temporarily use the cache as SRAM?
Alex
--
coreboot mailing list: coreboot@coreboot.org
Hi Allen,
There's less than 24 hours left to submit proposals. If you want to do this, I
suggest you get your proposal up before the deadline (March 21st). While I do
not know the details of your employment contract with ASUS, I find it
irrelevant for the purpose of you working on coreboot.
On Thursday, March 20, 2014 08:30:58 AM ron minnich wrote:
in the proposal. We'll deal with other issues later.
The guy that gave us the first real CAR implementation was an intel
employee who had NDAs out the ...
and it was not an issue.
Let's not start putting in roadblocks. We're
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote:
On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com wrote:
BTW, has any manufacturer been hostile in the past in any way relating to
coreboot supporting hardware they would rather have kept closed/secret?
ha ha ha ha ha ha
On Thursday, March 20, 2014 09:08:18 AM ron minnich wrote:
On Thu, Mar 20, 2014 at 8:36 AM, mrnuke mr.nuke...@gmail.com wrote:
BTW, has any manufacturer been hostile in the past in any way relating to
coreboot supporting hardware they would rather have kept closed/secret?
ha ha ha ha ha ha
On Thursday, March 20, 2014 09:36:06 AM ron minnich wrote:
How about, all of them at one time or another. One vendor had an
internal memo stating that anyone who talked to me (my name was on it)
about LinuxBIOS would be terminated.
You're popular it seems. How about within this decade
On Thursday, March 20, 2014 10:55:57 PM Stefan Reinauer wrote:
Changes to the coreboot Project Structure
Measures to improve the coreboot Development Model
* Require authors to acknowledge changes made in their name (Forge-Author)
[...]
Couldn't agree more.
* Define owners for (sets
I'll try to be short.
* Usually, ARM payloands need to use SoC specific drivers to access storage
devices.
* Sometimes coreboot implements the same drivers.
Proposal:
* Share these drivers between coreboot and libpayload.
* libpayload is BSD. Have a [ ] Enable GPL features config
On Friday, March 21, 2014 01:13:59 AM Peter Stuge wrote:
mrnuke wrote:
* Share these drivers between coreboot and libpayload.
* libpayload is BSD. Have a [ ] Enable GPL features config option which
unlocks the GPL'd drivers from coreboot.
* libpayload core remains BSD
On Wednesday, March 19, 2014 09:32:44 PM Stefan Tauner wrote:
On Wed, 19 Mar 2014 16:01:05 +0100
Peter Stuge pe...@stuge.se wrote:
I'd like somebody to look at doing LinuxBIOS again, i.e. getting us back
to
the point where we can embed linux in the flash as the payload. Patrick
got
On Saturday, March 15, 2014 05:15:12 PM Kevin O'Connor wrote:
Did you mean to send this only to me? I'm only sending to you and not
the list, but I'd prefer the discussion to be on list.
OOPS! I blame it on KMail's shitty Reply interface.
On Sat, Mar 15, 2014 at 01:54:47PM -0500, mrnuke
initialize the CBFS mirror once. If the code finds a valid CBFS
signature in RAM, it skips the whole re-read-this step.
[1]
https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268
c1
c9f2dc/src/cpu/allwinner/a10/bootblock_media.c
--
coreboot mailing list: coreboot
On Friday, March 14, 2014 12:23:03 PM Aaron Durbin wrote:
I found out that keeping track of the last map() pointer allows you to free
the cache during unmap(), as currently, operations come in map/unap pairs.
Sadly, this is just an accident of how CBFS core works. This design also
places the
On Friday, March 14, 2014 09:46:53 AM ron minnich wrote:
In other words, you can design a special case that makes doing a good
design of the general case almost impossible. That's been done too; see
UEFI.
:)
--
coreboot mailing list: coreboot@coreboot.org
On Friday, March 14, 2014 12:03:01 PM you wrote:
Just to step back here.
The flash is 8M. The system has 4G. What do I care if I leak memory? What's
the issue you are solving?
Thank you! You have pointed out the number one issue with this bullfart: that
CBFS design is x86-centric.
When
On Friday, March 14, 2014 02:07:59 PM Aaron Durbin wrote:
I don't recall the coreboot runs only very briefly. However, once
you do have ram the question is where does one get the ram? I think
you are trivializing the problem -- not impossible, but it's
definitely not just malloc().
I think
]
https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268c1c9f2dc/src/cpu/allwinner/a10/bootblock_media.c
[2] https://github.com/mrnuke/coreboot/commits/cubie_mmc
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Wednesday, March 12, 2014 08:03:04 AM ron minnich wrote:
On Wed, Mar 12, 2014 at 6:33 AM, Peter Stuge pe...@stuge.se wrote:
Do we want ACPI?
We've had it for years. Do we want UEFI runtime services? They're required
for ARM V8 ;-(
Are you telling me something like linux will have to
On Wednesday, March 12, 2014 05:07:33 PM Peter Stuge wrote:
Oh, and since we don't have a project-wide habit of distinguishing
between virtual and physical it seems that any use of paging
currently in coreboot can only be a big ugly hack. :\
It would break microcode updates on VIA Nano,
On Wednesday, March 12, 2014 07:08:16 PM Peter Stuge wrote:
A 1:1 mapping is (obviously, I hope) equivalent to not having paging
at all for the purpose of this discussion.
Not for Via NANO micrococde updates.
Alex
--
coreboot mailing list: coreboot@coreboot.org
Why don't we just configure the mail server to reject messages containing
HTML? Most instances of HTML I've seen have been accidental anyway. It's not
like there was ever an instance of html being useful here.
Alex
--
coreboot mailing list: coreboot@coreboot.org
On Monday, March 10, 2014 08:54:12 AM ron minnich wrote:
I think what we need to do is make this thread continue until it has
consumed more space then one month's worth of HTML.
I think we're still in the bikeshedding of original request stage.
First off, whining about usage of HTML because of
On Monday, March 10, 2014 06:11:41 PM Marcus Moeller wrote:
Hi all.
Is there a way to protect against re-flashing, e.g. by using a password
or an encryption key?
Don't believe everything you read in whitepapers and sales brochures.
Passwords and/or encryption have nothing to do with
This was supposed to go to the list, not Ron alone.
On Sunday, March 09, 2014 08:26:05 PM you wrote:
On Sunday, March 09, 2014 05:14:51 PM you wrote:
Story so far:
1. pick q35 chipset
2. qemu -M q35 etc. etc.
$ qemu-system-i386 -M q35 --bios build/coreboot.rom
-ENOREPRODUCE
1.
On Saturday, March 08, 2014 10:30:51 PM ron minnich wrote:
snip
q35 chipset. That's the only change I make.
qemu-system-x86_64 --bios build/coreboot.rom -cdrom tinycore.iso -boot d
+ -M q35
There, I fixed it for you!
Alex
--
coreboot mailing list: coreboot@coreboot.org
On Monday, March 03, 2014 06:05:49 PM ron minnich wrote:
The new chromeboxes are pretty compelling and modern, so it's hard to see
the case for those very old boxes.
Blobs?
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Wednesday, February 26, 2014 11:03:25 PM coreboot wrote:
#202: Error building coreboot for Samsung Exynos5 Google Snow
+--
Reporter: bluestore.logmein@… | Owner: stepan@…
Type: defect |
On Tuesday, February 25, 2014 07:46:50 AM ron minnich wrote:
I plan to use the intel code as as guide, but not pull it in directly. We
have source, we should do it right. I am going to take Aaron's suggestion
and structure it as baytrail is structured.
I was thinking we could put the existing
On Tuesday, February 25, 2014 07:28:04 PM Peter Stuge wrote:
Stojsavljevic, Zoran wrote:
This what I have proposed binds to current Coreboot FSP support/framework
Even though seamless integration of FSP with upstream coreboot is
probably what Intel would want that approach is not
On Wednesday, February 19, 2014 11:06:40 PM Paul Menzel wrote:
looking through `src/console/Kconfig` I noticed
You mean 'src/Kconfig' ?
if SOUTHBRIDGE_INTEL_BD82X6X DEFAULT_CONSOLE_LOGLEVEL_8
This is a layering violation. We shouldn't have hardware-specific options in
On Thursday, February 20, 2014 12:11:58 AM Paul Menzel wrote:
Until this is done, such data is lost and it is not nice to ask users to
rerun stuff again with such a patch. So please, could we just decide on
a name for the serial/USB debug log file and be done with this? Not a
lot of people are
On Tuesday, February 18, 2014 07:33:43 PM Peter Stuge wrote:
I'm sorry I said anything, I was silly to think that design
discussion would be possible.
I've been following this thread for the last couple of days, and I still have
no idea what you're talking about. I bet mostly everyone else
On Tuesday, February 18, 2014 12:21:38 AM amlo...@tfwno.gf wrote:
As a privacy and freedom oriented PC/Linux user, it scares me how modern
day devices are becoming extremely proprietary. Companies are beginning
to ship their laptops/tablets with proprietary EFI systems which have
some nasty
On Monday, February 17, 2014 08:24:12 AM ron minnich wrote:
downloadcenter.intel.com
gets the following error, and has for some time:
Cannot connect to the real downloadcenter.intel.com
Something is currently interfering with your secure connection to
downloadcenter.intel.com.
*Try
On Sunday, February 16, 2014 08:40:43 AM Oskar Enoksson wrote:
Ok, but when I look inside my DL145G1 the text AMD Serenade is printed
on the motherboard. In fact, HP DL145 G1 is not a motherboard, it's a
server which uses the AMD Serenade motherboard.
Does the vendor BIOS say HP DL145 G1 or
On Sunday, February 16, 2014 11:42:57 PM Peter Stuge wrote:
Denis 'GNUtoo' Carikli wrote:
[...]
The commits from your branch which you pushed with me as author and
which four other developers reviewed and finally submitted, without
spotting bugs present in some commits and with talking to
On Monday, February 17, 2014 06:27:34 AM Oskar Enoksson wrote:
On 02/16/2014 09:08 AM, mrnuke wrote:
On Sunday, February 16, 2014 08:40:43 AM Oskar Enoksson wrote:
Ok, but when I look inside my DL145G1 the text AMD Serenade is printed
on the motherboard. In fact, HP DL145 G1
On Monday, February 17, 2014 08:21:55 AM Oskar Enoksson wrote:
On Monday, February 17, 2014 06:27:34 AM Oskar Enoksson wrote:
On 02/16/2014 09:08 AM, mrnuke wrote:
On Sunday, February 16, 2014 08:40:43 AM Oskar Enoksson wrote:
Ok, but when I look inside my DL145G1 the text AMD Serenade
On Wednesday, February 12, 2014 03:16:43 PM ron minnich wrote:
let's do it this way. Why doesn't one of you just propose the wording.
Let's try this again:
* LICENSE_TAG: GPLv2+ (See README in top-level directory for explanation)
* LICENSE_TAG: GPLv2 (See README in top-level directory for
On Friday, February 14, 2014 12:38:58 AM Vladimir 'φ-coder/phcoder' Serbinenko
wrote:
Sure:
1) Locate intel offices
2) Locate their top-secret safes
3) Observe security
4) Buy military gear
5) Recruit and train a company (~200 people) for a year
6) Launch assault on the office
7) Break
On Tuesday, February 11, 2014 11:30:04 PM ron minnich wrote:
This note is motivated by mr.nuke.me's recent CLs with a short-form GPL
notice in them. I like that notice but I think it needs a tweak, then we
can just use it everywhere.
Which was motivated by some of your gerrit comments.
This
=== START_TLDR /* Skip to END_TLDR if you're short on time */ ===
It seems that we're using #if CONFIG_ like free coffee and cookies in a
conference. Without thinking too much of it. And we're using very much of this
in generic code, which is, as I will point out why shortly, a very bad idea.
I meant to send this to the list, not Ron alone. Sorry Ron.
On Wednesday, February 12, 2014 10:18:33 AM you wrote:
Note that if a file ALREADY has notice in it, then we don't change
anything. So, in the limit, we can start using this new notice for
(e.g.) your stuff and only apply it as we
On Wednesday, February 12, 2014 07:40:58 PM Peter Stuge wrote:
But there is generic and there is generic. If something is known
already at build-time then I think it's a bad idea to push the
decision to run-time.
And yet, we have many places where we take decisions which belong at runtime,
On Wednesday, February 12, 2014 07:44:42 PM Patrick Georgi wrote:
I like solving things at compile time that can be solved at compile time
(and in fact even earlier, if possible). No need to store Mister stole
my lollipop if the board is guaranteed to ship with one.
That's something we can
On Wednesday, February 12, 2014 01:00:59 PM you wrote:
I can also turn that around and say why store all debug strings if a
production system will never run above BIOS_SPEW ?
I meant BIOS_INFO here.
elegantly, and still boot, albeit at a reduced cock speed.
Please read that as clock.
Alex
On Thursday, February 13, 2014 02:21:14 AM Peter Stuge wrote:
Don't confuse the product that ships with coreboot for what it
becomes after you've modified it.
Are we bikeshedding the example here?
Do you expect Intel to give you support after you've overclocked
their CPU way out of the spec
On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder'
Serbinenko wrote:
If we let user supply
files at all, it should be added to report, not replace files, and it
should have some prefix to clearly indicate that user was involved in
creating them. E.g. user_serial_log.txt
On Saturday, February 08, 2014 05:30:38 PM Peter Stuge wrote:
If the project could change to work somehow differently and that
would help contributors then I think that's something we should
consider identifying and doing.
Allow git merging. Forced cherry-picking is a PITA for almost
1 - 100 of 164 matches
Mail list logo
