On Tue 22/02/11 23:58 , "Alex G." <mr.nuke.me(a)gmail.com> wrote:
> On 02/22/2011 02:47 AM, Peter Stuge wrote:
> > Xavi Drudis Ferran wrote:
> >> Does everyone prefer to have it not include update_microcode.c and
> >> change romstage.c in those boards that call update_microcode(...) ?
> > At least I like this better. It makes it clear what effect this
> > option has for mainboard code.
> If this option ever existed, I want it to stay out of my way entirely. I
> don't even want to know it exists without explicitly searching for it. I
> don't want to ever be in the situation where I find out that my board
> froze because the microcode update was disabled, and I don't want
> newcomers to waste their time asking about that pompous sounding
> "Disable Microcode update" option in menuconfig.
If you look at the patch the option name is
+ bool "Update cpu microcode"
+ default y
and it's "y" by default, so you won't get your microcode update disabled unless
all these happen:
- you have a FAM 10 cpu
- you make menuconfig (or similar)
- you go to the chipset menu and under title CPU unselect the preselected option "Update cpu microcode"
If that is too visible for you I don't know how to build an option that different users
may enable or disable.
If you mean visible in the source code:
the patch I sent changes only one .c file and one Kconfig file. The function update_microcode()
would still exist and it would do the update or do nothing depending on CONFIG_UPDATE_CPU_MICROCODE.
No other files would need touching.
This is what my software engineer intuition recommends, centralise changes in one place, change
the behaviour of a procedure depending on configuration options, don't change every single place
that procedure is called.
But people have considered this to be too little visible, or too little invasive for its heretic nature,
or I don't quite understand what, and they've asked
so that update_microcode.c does not get compiled in. when CONFIG_UPDATE_CPU_MICROCODE is false
since in that case the function update_microcode(...) would be undefined, we would have to also
change all files with a call to it, by placing an #if around the call. Those files are
(and by */* I mean all or some of the fam 10 boards, not all boards).
And I can even imagine another
change update_microcode.c so that when CONFIG_AMD_UCODE_PATCH_FILE is defined
to be an empty string or 0 or something, then mc_*.h does not get
included into update_microcode.c, the update_microcode function does
not find microcode to update and it ends up doing nothing.
I don't think this is desirable because then this would be a mainboard
option, not a user option, and you might need different mainboard dirs
for different CPU revisions or just for different user choices. So I won't
send a patch for this. But someone might.
If I understand you I think you would prefer option A, so that the change is not
so visible in source code, but maybe you want C because you don't want to
see it in make menuconfig at all . I'd appreciate some more detail.
About newcomers complaining because they've disabled microcode update,
it's not somethign that would happen without user action, and we already
have newcomers (Ivaylo and I) complaining because the microcode update
it giving us trouble. We can add a note in Kconfig help like :
"If you unselect this option and have some problem you want to ask
about in the coreboot mailing list (or elsewhere) please report clearly
you disable microcode update, since some developers strongly advise against this."
> If I _really_ wanted to disable microcode updates, I would simply
> comment out a line of code.
That's what I did ! But I found out there were more people than just myself
wanting this option, so I tried to code a patch that would change nothing
for those who wanted the old behaviour but would allow to disable microcode
update and keep testing new svn revisions, sending patches, etc. without
the hurdle of a local modification, for those of us that need it.
If I had know how polemic it all would become I've probably hadn't sent
the "pompous" patch at all.
> As far as the licensing discusion gooes, I have thought of this
> intensely. I don't see microcode as violating my freedom. It is
> hardware. modifying microcode modifies the hardware. This is something
> that software cannot do.
Violating licenses is not the same as violating freedom, and freedom from
lawsuits is also something one mike like. Also being kind to people you
take code from and considering they might consider hardware as the part
of an information system that you cannot change (excluding people) and
software as the part that you can change, even if you think they're wrong
and microcode is hardware, has some ethical value.
But I won't follow along this route, because we simply don't agree in enough
categories to agree in this.
> + We are firmware developers, not hardware engineers.
May I remind that the patch does not modifiy the microcode creatively ?
It just leaves as it was the microcode that the "hardware" engineers
installed in the factory ? Some people have found that version of the
"hardware" to work better than the "modified hardware" after microcode
> I'm not voting no on this, just so as long as it is completely invisible
> to me.
Please specify which of Option A, B, or C do you prefer, or propose something
else, if you don't vote no. I can't code a completely invisible patch to a free software
project that evolves in the open like coreboot.
Whatever I do you will see it if you look at it.
Dear coreboot community,
it is really amazing what happened in the last years and especially in
the last months. A lot of people came – for me – out of nowhere and did
great contributions. Also AMD did great with their latest contributions
Today, Scott sent a patch to the list to support the board ASRock E350M1
[2, 3, 4]. If I am not mistaken there have been only a few cases, it
could be the first, where such a *recent* consumer board is supported by
coreboot. And that is the reason I am writing this message.
This also means that most of the computer magazines (online – at least
in Europe – and print) have not yet published reviews and the board is
not yet old enough to be considered by consumers. You guys have more
experience than I on how these reviewer networks work, but is there an
easy way to get these boards tested by these people with coreboot?
I came up with the following steps to be accomplished to reach that
1. Contact ASRock. Does anyone have contacts at ASRock to get
documentation or even hardware or man power?
2. Get Windows running. Scott wrote that Windows does not boot yet.
Since the market share of Windows in the home desktop market is
still the biggest, that would of course be a requirement.
3. Get GNU/Linux running. I think FLOSS users are more open to try
new things. So to get to them, GNU/Linux should at least be able
4. Wiki page and feature list. A page in our Wiki  should be set
up with detailed instructions on how to create an image, what
features (ACPI, power management, suspend/resume, connectors, …)
work and, when the patch is committed, what revision was tested.
5. Comparison with the vendor BIOS. People of course would only be
interested if coreboot is superior to the vendor BIOS. And I
would imagine that normal users would be most interested in boot
time. Is coreboot faster?
6. Flashrom support or “precompiled” images. To make it easy for
the reviewers and early adopters flashing using Flashrom should
work or precompiled images should be made available, if it is
legally possible, and even flash chips offered or send to the
reviewers which they can easily plug into the board and start
testing. Is there a foundation (e. g. FSF), organization or
cooperation (e. g. Google) which could sponsor to buy like
200(?) spare flash chips, which then can be programmed? What
flash chips are compatible with this board?
7. Contact everybody. When all of the above has been accomplished,
the magazines, reviewing sites, news sites, LUGs, communities
should be informed. Magazines get the chips send to and
consumers can order them from a coreboot developer.
Do you think that is a feasible roadmap? If yes, a lot of testing and
work needs to be done and Scott, of course, cannot do that alone. So
people willing to help, should get a this board, spare flash chips, and
start mostly testing. I am not a developer, so I could not help to
improve the support, but I could test and maybe even create a live image
to flash that image from an USB storage device.
It looks difficult though to get this board .
Another chicken and egg problem is, if this announcement should be made
public outside of the coreboot community only after support is complete
or before, i. e., are there communities (e. g. FSF) or project
developers which would help to support this effort?
Unfortunately CeBit is going to already start next week, so we will not
be able to show the new support off there.
I am looking forward to your thoughts. Thanks,
Date: Sun Feb 27 03:48:41 2011
New Revision: 6386
Add 300 MHz and 500 MHz HT frequency limits
Needed to build successfully with Expert mode enabled.
Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat>
Acked-by: Peter Stuge <peter(a)stuge.se>
--- trunk/src/northbridge/amd/Kconfig Sun Feb 27 00:29:44 2011 (r6385)
+++ trunk/src/northbridge/amd/Kconfig Sun Feb 27 03:48:41 2011 (r6386)
@@ -24,8 +24,12 @@
bool "Limit HT frequency to 200MHz"
+ bool "Limit HT frequency to 300MHz"
bool "Limit HT frequency to 400MHz"
+ bool "Limit HT frequency to 500MHz"
bool "Limit HT frequency to 600MHz"
On 02/26/2011 11:43 PM, Patrick Georgi wrote:
> Am Samstag, 26. Februar 2011, 23:27:47 schrieb Alex G.:
>> Why bother holding dear to romcc when the obvious solution is to move
>> those boards to CAR? We introduce more unneeded complexity, and make it
>> at least just as hard to phase out romcc.
> Those boards carry CPUs without CAR.
Then those boards are most likely old and obsolete. Is it worth still
supporting them? "Support for this board was dropped with revision
'xyzw'". Do we want to make it xyzwq ?
> As for phasing out such support: That would be easy (just drop everything
> guarded in CONFIG_ROMCC in the build system).
Yeah, wasting countless hours fixing something that should have been
done long ago is fun. Oh wait, you guys are grep/sed masters; nevermind
On 02/26/2011 10:50 PM, Patrick Georgi wrote:
> Am Samstag, 26. Februar 2011, 14:17:37 schrieb Alex G.:
>> 3) add a romstage-$(CONFIG_THIS_SUPERIO) += early_serial.c to the
>> superio's Makefile.inc
> This will fail for romcc boards, as for them, romstage must be compiled by a
> single romcc invocation.
If we break romcc boards in an effort to efficientize the code base, I
am all for it, just so as long as we plead to fix it not much later down
> I planned to work on this by having the build system generate a wrapper for
> romcc boards automatically (essentially a file in $(obj) with romstage.c and
> other .c files #included, properly hidden from the dev), but that has some
> issues with the right order in which things must be included (romcc doesn't
> support forward declarations).
Why bother holding dear to romcc when the obvious solution is to move
those boards to CAR? We introduce more unneeded complexity, and make it
at least just as hard to phase out romcc.
I just found out how to take the PCIe x16 out of reset.
Following patch fills in the callbacks for PCIe x16 resets. This board uses
GPM8,GPM9 as reset toggles.
Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
I'm a lurker here (keep up the great work everyone! <3), but I saw this and
thought it looked relevant to coreboot development that a link should be posted.
Quoting from the website:
> The Intel BIOS Implementation Test Suite (BITS) provides a bootable pre-OS
> environment for testing BIOSes and in particular their initialization of
> Intel processors, hardware, and technologies. BITS can verify your BIOS
> against many Intel recommendations. In addition, BITS includes Intel's
> official reference code as provided to BIOS, which you can use to override
> your BIOS's hardware initialization with a known-good configuration, and then
> boot an OS.
I haven't looked into it deeply enough and nor have I used coreboot enough to
know if it will be helpful, but I certainly hope it will.
Dear coreboot readers!
This is the automatic build system of coreboot.
The developer "sduplichan" checked in revision 6383 to
the coreboot repository. This caused the following
Correct error in ASRock E350M1 commit that breaks build for ASRock 939a785gmh.
Signed-off-by: Scott Duplichan <scott(a)notabs.org>
Acked-by: Peter Stuge <peter(a)stuge.se>
Compilation of asrock:939a785gmh has been fixed
If something broke during this checkin please be a pain
in sduplichan's neck until the issue is fixed.
If this issue is not fixed within 24h the revision should
be backed out.
coreboot automatic build system