The ROMSTAGE on ARM is expected to be SRAM. When you know the SRAM
address for a given mainboard, you need to set it up in Kconfig for
*just* that mainboard.
Nice work, I think you're getting close!
ron
--
coreboot mailing list: coreboot@coreboot.org
I'm sure it could run were someone to implement it.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
So, if you comment that one line out, do things work for you? Just
double checking.
ron
On Mon, Aug 11, 2014 at 2:09 AM, Piotr Król pietrush...@gmail.com wrote:
On Mon, Aug 11, 2014 at 12:15:32AM +0200, Peter Stuge wrote:
There is no coreboot gdb support
There is some gdb support in
got accepted. See you there.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
There's lots of really nice work going on with clang and other tools.
I just want to put out a word of caution, based on what I'm seeing.
A number of these tests are going in with global changes, no testing,
and in some examples, no clear improvement or bug fix, e.g. remove
all blank lines at the
:42AM -0700, ron minnich wrote:
So, if you comment that one line out, do things work for you? Just
double checking.
Comment is not enough to make it work. VE_NORFLASHALIAS has to be -1, then it
works for me. So patch for QEMU is:
diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index a88732c
So what this is saying is that we expect the ROM for coreboot to start
at 64K. I hope this makes sense to you. Does this conflict with some
qemu expectation, do you know?
ron
On Mon, Aug 11, 2014 at 3:37 PM, Piotr Król pietrush...@gmail.com wrote:
On Mon, Aug 11, 2014 at 01:51:16PM -0700, ron
Sorry, in other words, how much ROM are you setting up on that qemu
board? The 'execute outside ram or rom' is usually a jump to an IP
that qemu does not recognize as ROM/RAM.
I suspect our emulator is assuming SRAM in there somewhere, can you
check? Certainly we depend on SRAM on the real
You can't assume much of anything. That commit seems not that harmful.
What would help is if you tell us more about when the problem happens.
There's just not enough info in your note, but I'd love to try to
help.
Thanks!
ron
On Sun, Aug 10, 2014 at 12:57 PM, Piotr Król pietrush...@gmail.com
One of the reasons Im working to implement paging for 32-bit mode is
for our eventual change to 64-bit mode for coreboot. It's gone on the
back burner for a bit as I'm doing a few other coreboot things first.
I'd love to have the help, if you have time.
ron
On Sun, Aug 10, 2014 at 1:02 PM,
On Sun, Aug 10, 2014 at 2:48 PM, The Gluglug i...@gluglug.org.uk wrote:
What about 32-bit-only machines, or people that want to use a 32-bit OS?
well, we won't compile 64-bit firmware for 32-bit machines, if that
helps. See: ARM v8 vs. v7.
And a 32-bit OS can run on a machine with 64-bit
I understand the arguments.
It's worth remembering that coreboot has to date run on 5 different
architectures. 4 of those used paging. The x86 has always been the
outlier. Lack of paging has costs not discussed much. Rmodules would
be a lot simpler if we had paging. We could make the code space
Some of furquan's very fine work from -- yegads! -- a year ago is just
now coming upstream. Take a look.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
These power supply issues are quite fun, like other things. The mistake
would be to say that, because there is noise, coreboot is wrong and vendor
firmware is right. It can be far more subtle than that. It could even be
the case that coreboot is right, the vendor code is wrong, and the
correction
On Tue, Jul 22, 2014 at 10:55 AM, Peter Stuge pe...@stuge.se wrote:
ron minnich wrote:
wrong
right
It's way too early for that Ron. At this point nobody even
understands wtf is causing the problem. Someone competent
needs to research that before a discussion about the solution.
I'm
Comic sans
http://www.aspire1.ru/_pu/0/s14086199.jpg
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
we had this recently in another context. A log would be useful. It will try
to find a bounce buffer if your payload will end up replacing parts of
coreboot. What is your base/size for coreboot and for the payload?
ron
--
coreboot mailing list: coreboot@coreboot.org
On Wed, Jun 25, 2014 at 4:11 AM, benjamin nakache bnaka...@nolam.com
wrote:
Hello ,
When will support the new Atom E38XX
Would you or someone from your company like to help?
Note: This message and any attachment hereto is intended solely for the
use of the designated recipient(s)
I had not seen this, maybe you all have, but:
http://inertiawar.com/microcode/
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
.
On Tue, Jul 8, 2014 at 12:27 PM, ron minnich rminn...@gmail.com wrote:
I had not seen this, maybe you all have, but:
http://inertiawar.com/microcode/
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot
no, that is not early enough on some CPUs.
ron
On Tue, Jul 8, 2014 at 11:20 AM, yhlu yingha...@gmail.com wrote:
On Tue, Jul 8, 2014 at 10:39 AM, ron minnich rminn...@gmail.com wrote:
you can no longer update microcode after the kernel boots (on modern
Intel
CPUs). It has to happen
recent chipsets. Yes, you might get it to
boot. That's almost worse than having it fail.
ron
On Tue, Jul 8, 2014 at 11:26 AM, Scott Duplichan sc...@notabs.org wrote:
ron minnich [mailto:rminn...@gmail.com] wrote:
]you can no longer update microcode after the kernel boots
](on modern Intel
On Tue, Jul 8, 2014 at 1:07 PM, Peter Stuge pe...@stuge.se wrote:
I think very specific details would strengthen this argument. I'm not
saying that the argument is wrong, I'm saying that it would be great
to learn about specific experience.
you are absolutely right. I'm just trying to
Thanks for the good examples, Patrick.
So I'll say it one more time: while I understand the concerns about the
microcode blob, and I appreciate the sincerity of those who want to build
coreboot images that don't have them, I think it's a huge mistake to take
that path on almost anything made in
So Rudolf, this just takes the control loop out of the picture and always
enables the fan? This stuff always confuses me.
ron
On Sun, Jul 6, 2014 at 1:47 PM, Rudolf Marek r.ma...@assembler.cz wrote:
Hi
I think this is the problem: change the following line in the devicetree.cb
register
Charles, just checking, you know the deal, right? Room at the top of the
physical address space is saved off for PCI. Hence memory in that range is
not addressable.
Chips that could hoist memory in the, e.g., 3g-4g range up above 4G have
been around since before the i945. Anybody know for sure
as a first pass, did you burn coreboot for the wrong board just to see if
you got anything al all on serial? I just went through this process on
a different board and that was my starting point, as it is for many.
ron
--
coreboot mailing list: coreboot@coreboot.org
I think it's fine. The more info we have on a given board the better, and
the boot log seems to be of value to people, so why not?
ron
On Thu, Jul 3, 2014 at 7:30 PM, Martin Roth martin.r...@se-eng.com wrote:
I've added a routine to grab the boot log for the board-status database
from a
On Thu, Jul 3, 2014 at 4:18 PM, David Hendricks dhend...@google.com wrote:
Necromancing this thread...
Sage has a patch to *optionally* use a serial console log in
board_status.sh: http://review.coreboot.org/#/c/6094/
Earlier objections to such an approach seemed to stem from either:
-
This is great. We've gotten an acer c720 down to 1.7 seconds from power
button to chromeos login screen. I've always wanted to get it done in under
a second. I hope you can get there!
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
As always, when doing a new board, get a system that is known to work with
coreboot and has your chipset in it. You should get several (never just
one!) of the haswell chromebooks, build coreboot, make sure you can make it
all work, then try the port to your board.
ron
On Wed, Jul 2, 2014 at
Double check: the chassis fan turns off. Sometimes, that's correct behavior
until things get warm, and the fan should turn on.
So you're sure the turning off is the wrong thing to do? In some cases it's
desirable for a chassis fan to spin up, then turn off, then turn on again
as needed, all under
a Chromebook wearing Coreboot and
Haswell based.
-
Gregg C Levine gregg.drw...@gmail.com
This signature fought the Time Wars, time and again.
On Wed, Jul 2, 2014 at 12:09 PM, ron minnich rminn...@gmail.com wrote:
As always, when doing a new board, get a system that is known to work
/merged in. Also works for the nearly-identical HP ChromeBox
(zako). I can throw my branch up on github in the meantime if would be
useful, but that's where I'd recommend starting (vs the ChromeBooks).
cheers,
Matt
On 7/2/2014 11:09 AM, ron minnich wrote:
As always, when doing a new board
I like that date, it fits really well with ELC.
ron
On Mon, Jun 30, 2014 at 11:04 PM, Rudolf Marek r.ma...@assembler.cz wrote:
Hi all,
What about 16 17 18 19 of October then? It is already in the university
semester so there could be trouble with dormitory accommodation, but I
think no
Yeah, that's a great idea.
ron
On Mon, Jun 30, 2014 at 3:53 PM, David Hendricks dhend...@google.com
wrote:
On Sun, Jun 29, 2014 at 2:06 PM, Rudolf Marek r.ma...@assembler.cz
wrote:
Hi all,
First of all sorry that it took so long to get back to this.
I have in plan to organize a
On Fri, Jun 20, 2014 at 10:00 PM, Scott Duplichan sc...@notabs.org wrote:
Putting the serial number in the same flash chip as the main
firmware is a cost reduction measure used with desktop and other
low cost boards. I have even seen a board where the MAC address
lives there. The only
On Fri, Jun 20, 2014 at 11:20 PM, Patrick Georgi patr...@georgi-clan.de
wrote:
In the end, I pose the question why a serial number must be exported to
the OS in the first place - this looks like a potential privacy issue to
me, while doing nothing for servicing the part (if it's sent back,
On Sat, Jun 21, 2014 at 5:17 AM, Karl-Heinz Nirschl kh.nirs...@gmail.com
wrote:
But anyway - the real statement of the message meant to be: thanks for
all the good code.
That's very kind of you. I think you are right about the code, it has
improved a lot in the last couple years.
ron
--
realistically, though, it's hard for me to see how setting the serial # at
firmware image build time scales. And setting it after boot makes no real
sense either -- it's not really a serial number if you're changing it at
that point.
But some way to customize the binary images with a serial
On Mon, Jun 9, 2014 at 6:00 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
Dear Ron,
Please also note, that at least since Linux 3.11, Linux is not able
anymore to set up graphics without the Video ROM or native graphics
init. Unfortunately, nobody bisected this yet or notified
It's painful and awful to do, but when you get that error, I suggest you
mod the driver to hexdump the ENTIRE gtt. You need to see what's going on
there.
It's possible that somehow the gtt and gsm are living in the same place and
the chipset is corrupting its own gtts.
ron
--
coreboot mailing
BTW, as you'e seen, the data sheets are less than helpful. But the driver
is usually worth looking at.
My contact at Intel tells me he's not seeing what you're seeing, so we need
a way to reproduce your setup and see what's going on.
ron
On Mon, Jun 9, 2014 at 7:15 AM, ron minnich rminn
Folks, do I correctly understand this regression is X60-only? In that case,
I suspect there will not be lots of interest in fixing it from the kernel
side :-(
sorry
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Paul, many good questions. The problem is I did all this over 2 years ago
and the answers won't be as good. Vladimir and Peter will likely do better.
And, to reiterate, the 'replay attack' code for Link is not a good example
of how to start graphics. It Just Worked, but not well. The second
Does anybody want to have a go at a further interpration of the errors?
That would help. Does this error mean a present bit was not set, or the
address was wrong, or ...
ron
On Sun, Jun 8, 2014 at 4:40 PM, Anthony Martin al...@pbrane.org wrote:
Paul Menzel paulepan...@users.sourceforge.net
On Wed, Jun 4, 2014 at 1:11 AM, Gerald Otter gerald.ot...@gmail.com wrote:
Just for my own understanding; is it common for microcode loading to be
required as part of the booting process, as opposed to being optional
updates?
Yes. Long ago, we let the kernel load microcode. Then, at some
Congrats!
ron
On Wed, Jun 4, 2014 at 9:25 AM, Mark C. Mason m...@edt.com wrote:
We are running Linux from Coreboot this morning, after adding
a bootable device on the SATA port.
The USB boot devices were never seen, so more work to do there.
Thank you for all your help!
Best regards,
On Wed, Jun 4, 2014 at 11:59 AM, WANG FEI wangfei.ji...@gmail.com wrote:
I thought microcode files are kind of patches for CPU, it suppose to be
loaded before MRC just in case it fixes any issues related with CPU. I
actually did encounter an system random halt issue related with no loading
On Wed, Jun 4, 2014 at 1:57 PM, Martin Roth martin.r...@se-eng.com wrote:
There are a number of issues here:
3) The way that the microcode is currently being included is (to my
understanding) completely against the Intel licensing. We're compiling a
.h file with a license that says that
And never forget, no matter how many times we try to get this right, some
vendor will come up with a way to break a naming scheme. Happens every time.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Peter, I completely agree.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I'd drop every other thing you're doing and get that usb debug port going.
It will save your mind.
But, yes, it seems you're getting pretty far.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I thought you had to go further back than 2009 to get pre-AMT chipsets,
was I wrong on that?
ron
On Thu, May 29, 2014 at 4:44 PM, Silkie Carlo silkieca...@gmail.com wrote:
Hi guys,
I do hope you can help me! I am working on an infosec project at the
moment, trying to fight the good
has anyone looked at camlistore as a starting point? Written in Go,
which means it works on Plan 9.
ron
I'm beginning to remember why I redirected this list to /dev/null. I
think I'm going to resume.
Enjoy your ever-shrinking place in the world, folks; it's clear that
you enjoy it. It's also clear that nobody else cares any more.
ron
There was a time, quite some time ago, when somebody was booting
vxworks from linuxbios, i.e. it was the payload.
ron
On Thu, May 22, 2014 at 6:55 AM, Stojsavljevic, Zoran
zoran.stojsavlje...@intel.com wrote:
Hello Peter,
I'll try to find answers to these questions. I might even myself build
I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.
If you are telling me that the upgrade technology of Plan 9 can not
handle an automatic upgrade, fine; we have
Ah well, back to 'm' for this thread, and I now accept that this
community is unwilling to solve this simple problem, as so many others
have. Bummer.
ron
I certainly like seeing the words 'mortem' and 'EFI' in the same email ;-)
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
I've been watching the discussion but was hesitant to jump in. But
somebody asked me to say a thing or two.
We put the nsec() system call into NxM because, any way you cut it, it
provides better accuracy than the open/read/close path, particularly
when there's lots of stuff running, and the apps
On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
charles.fors...@gmail.com wrote:
Jitter says something about (in)consistency of time periods or intervals. It
will be a function of scheduling decisions, not the overhead of a single
call.
In Nix, on an AP core, sure, because there isn't any
On Mon, May 19, 2014 at 3:05 PM, erik quanstrom quans...@quanstro.net wrote:
the documentation appears not to cover this completely.
Hmm. You put documentation and completely in the same sentence. Agents
are converging on your house. Run!
There's always an undocumented progress engine
I've done this, and I've forgotten how. I need to tell 6l to link a
program to run at
0x7f00
I've tried various combos of -T, -R, and -D and am failing to get the
right result ... any hints to revive my poor memory would be welcome.
ron
you need to give more credit to the compiler :-)
the address I'm using is in the low half of the address space.
But I'll wait for Charles to weigh in and tell us what's what.
ron
what's an EFI OS?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Tue, May 13, 2014 at 5:29 AM, Peter Stuge pe...@stuge.se wrote:
That's an important question, but I believe the answer is no.
That's all I wanted to know, to start.
So why don't we just get that CL in and see where we go from there.
Thanks all. And sorry if I was too hard on kolibrios.
On Mon, May 12, 2014 at 12:13 PM, Peter Stuge pe...@stuge.se wrote:
Why shouldn't coreboot do legacy initialization? What is the reason
to be *less* compatible than possible?
The main question I had was whether enabling this set of interrupts
could negatively impact other payloads. The goal of
Like I say, if it's not going to do harm, and you all want it, submit the CL.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
somebody referred me to the discussion.
Sometimes we found people wanted to build on their existing OS (Linux,
OSX, whatever) in a cross-build way, and, further, didn't want to do
that in a VM, because they had tools they liked.
github.com/rminnich/NxM is the last snapshot of the Sandia/BL fork,
On Fri, May 9, 2014 at 1:51 PM, Bakul Shah ba...@bitblocks.com wrote:
Full plan9 *native* build of the kernel, libs and bin on a
/RapsberryPi/ is about 4 minutes
GOOD. Why not have a web page? The great plan 9 build shootout. Nobody
would be happier than me if Linux always lost.
ron
On Fri, May 9, 2014 at 2:46 PM, Charles Forsyth
charles.fors...@gmail.com wrote:
On 9 May 2014 21:37, ron minnich rminn...@gmail.com wrote:
under the Inferno license for that matter
that's usually MIT
Yeah. Either 3 clause BSD or MIT work. Many others don't. So whichever
one of those
How good is the FSP code with a new board?
I have an SNB board and I'm curious as to how much blood will be on
the walls if I try to use an FSB-based coreboot image with it.
SNB = my weird way of saying sandybridge
ron
--
coreboot mailing list: coreboot@coreboot.org
Oh no, I don't want to try FSP, I just want to do the thing that's the
least work for me, and it sounds like Google mrc.bin is what I want,
since I know where to find it :-)
Thanks
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Sorry to miss it! Take many pictures!
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
IT will probably run u-boot, so free is solved.
But, wow, I think the price to what-you-get ratio on that thing is not
attractive.
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
So, how would these changes affect other payloads?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Thanks, that's a great explanation. Generally, we've tried to avoid
too much hardware setup in coreboot; that's the job of the kernel. I'm
not really happy that we're doing all this PIC setup for one OS,
written in assembly. It's been quite some time since I've had to use
PIC mode at all.
Why
Jiming, why doesn't intel just put that more open stuff up on github
and be done with it?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
well, you may not like the missing trackpoint, but a couple million
chromebook and macbook users are doing just fine.
It's all about the numbers.
ron
On Sat, May 3, 2014 at 2:52 AM, Stefan Tauner
stefan.tau...@alumni.tuwien.ac.at wrote:
Alex, you have missed something very important here:
0:
Anybody out there know typical numbers for the timer tick if USB is
active as part of SMM?
I just heard one number for one product line, 8 HZ. We're seeing a
mysterious 18 HZ tick on one system. Any other numbers people know?
thanks
ron
--
coreboot mailing list: coreboot@coreboot.org
well, as long as we're off topic, the El Patron restaurant in
Albuquerque was quite good.
And it looks like the new Fit is a great car, although I still think
the 2007 model year had more of a road feel.
Oh, wait, what mailing list is this again? I thought it was the ~coreboot list.
ron
--
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 will see it, or that it's pretty
rude on top of that, not so
Can somebody give me a sanity check? I can't see the error with the macro.
I won't say too much here -- just take a look. I'm not convinced the
code is wrong.
thanks
ron
On Fri, Apr 18, 2014 at 7:39 AM, WANG FEI wangfei.ji...@gmail.com wrote:
Ronald,
I just noticed a bug in your code, I've
Still not seeing it.
I think the order should be
' ', 'S', 'S', 'B'
not ' ', 'B'','S','S'
or 'B','S','S',' '
i.e. space is the high order byte.
ron
On Fri, Apr 18, 2014 at 8:21 AM, Nico Huber nic...@gmx.de wrote:
On 18.04.2014 16:49, ron minnich wrote:
Can somebody give me a sanity
Which of course means my code IS wrong, but the suggested fix is wrong
too I think.
ron
On Fri, Apr 18, 2014 at 8:34 AM, ron minnich rminn...@gmail.com wrote:
Still not seeing it.
I think the order should be
' ', 'S', 'S', 'B'
not ' ', 'B'','S','S'
or 'B','S','S',' '
i.e. space
Fooey. Now they all look wrong.
I think the macro maybe should be defined as makemagic(b0,b1,b2,b3)
the thing I can't figure out is why this ever worked.
OK, off to the dentist, ...
ron
On Fri, Apr 18, 2014 at 8:34 AM, ron minnich rminn...@gmail.com wrote:
Which of course means my code
.
On Fri, Apr 18, 2014 at 4:52 PM, Aaron Durbin adur...@chromium.org wrote:
On Fri, Apr 18, 2014 at 9:49 AM, ron minnich rminn...@gmail.com wrote:
Can somebody give me a sanity check? I can't see the error with the
macro.
I won't say too much here -- just take a look. I'm not convinced
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 :-)
ron
--
coreboot mailing list: coreboot@coreboot.org
And a little warning here. This is the PC business, and the version
control on hardware is just terrible.
So, you may have a board called the blackrock m23551-rev 3/Z, and
somebody else may have the blackrock m23551-rev 3/Z, and they may be
utterly different, because you bought yours on a
I'm a huge fan of tinycore.
So, could we ever have tinycore in flash? Man that would be nice. Talk
about instant on!
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
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.
Another addition to the blob matrix. sigh.
It's really not that just one vendor is bad and one is good. AMD has
its issues too.
It's a wonder I have any
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.
We can't get anywhere calling people names like this.
ron
--
coreboot mailing list: coreboot@coreboot.org
On Fri, Apr 4, 2014 at 5:28 PM, mrnuke mr.nuke...@gmail.com wrote:
That's just a reference to South Park.
Which would be fine if everyone on this list was a native English
speaker and knew what South Park was. Else, they could naturally take
offense, so please keep that in mind.
While I think
And here's where we thank Intel, btw. They've done a truly wonderful
job of getting code into the Linux kernel that I was able to use to
open up chipset init for sandybridge, ivybridge, and haswell, A tip of
the hat to Intel and Jesse Barnes especially for all they've done in
that area.
So let's
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
dropbox for others to try out? Not clear at all!
And, one backup copy?
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
act. The vendors are rightsholders too. They have knowledge we need.
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?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
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 demonstrates
how little I understand about who and what is
On Wed, Mar 26, 2014 at 5:00 PM, Thom Lauret opentho...@me.com wrote:
That disassembly is
required to identify the flash chip is going to slow coreboot adoption.
um, what?
ron
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
801 - 900 of 6555 matches
Mail list logo
