coreboot February 2011

coreboot@coreboot.org

52 participants
283 discussions

Re: [coreboot] [PATCH] disabling microcode update
by Xavi Drudis Ferran 27 Feb '11

27 Feb '11

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. > Pompous ? If you look at the patch the option name is +config UPDATE_CPU_MICROCODE + 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: Option A: 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 Option B: change src/cpu/amd/model_10xxx/Makefile.inc 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 src/cpu/amd/model_10xxx/init-cpus.c src/mainboard/*/*/romstage.c (and by */* I mean all or some of the fam 10 boards, not all boards). And I can even imagine another Option C: 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 update. > 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. Thank you.

6 20

[RFC] marketing coreboot after recent support of AMD board
by Paul Menzel 26 Feb '11

26 Feb '11

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 [1]. 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 goal. 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 to boot. 4. Wiki page and feature list. A page in our Wiki [5] 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 [6]. 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, Paul [1] http://www.coreboot.org/News#2011.2F2.2F14_AMD_submits_coreboot_support_for… [2] http://www.coreboot.org/pipermail/coreboot/2011-February/063737.html [3] http://www.asrock.com/mb/overview.asp?Model=E350M1 [4] http://notabs.org/pictures/ASRock-E350M1/ [5] http://www.coreboot.org/Welcome_to_coreboot [6] http://www.coreboot.org/pipermail/coreboot/2011-February/063757.html

4 4

[commit] r6386 - trunk/src/northbridge/amd
by repository service 26 Feb '11

26 Feb '11

Author: stuge Date: Sun Feb 27 03:48:41 2011 New Revision: 6386 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6386 Log: 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> Modified: trunk/src/northbridge/amd/Kconfig Modified: trunk/src/northbridge/amd/Kconfig ============================================================================== --- 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 @@ config LIMIT_HT_SPEED_200 bool "Limit HT frequency to 200MHz" +config LIMIT_HT_SPEED_300 + bool "Limit HT frequency to 300MHz" config LIMIT_HT_SPEED_400 bool "Limit HT frequency to 400MHz" +config LIMIT_HT_SPEED_500 + bool "Limit HT frequency to 500MHz" config LIMIT_HT_SPEED_600 bool "Limit HT frequency to 600MHz" config LIMIT_HT_SPEED_800

1 0

[commit] r6385 - in trunk/src: cpu/amd/model_10xxx mainboard/amd/bimini_fam10 mainboard/amd/mahogany_fam10 mainboard/amd/serengeti_cheetah_fam10 mainboard/amd/tilapia_fam10 mainboard/asus/m4a78-em ...
by repository service 26 Feb '11

26 Feb '11

Author: stuge Date: Sun Feb 27 00:29:44 2011 New Revision: 6385 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6385 Log: Make AMD Fam10h CPU microcode updates optional in Expert mode Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/src/cpu/amd/model_10xxx/Kconfig trunk/src/cpu/amd/model_10xxx/Makefile.inc trunk/src/cpu/amd/model_10xxx/init_cpus.c trunk/src/mainboard/amd/bimini_fam10/romstage.c trunk/src/mainboard/amd/mahogany_fam10/romstage.c trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c trunk/src/mainboard/amd/tilapia_fam10/romstage.c trunk/src/mainboard/asus/m4a78-em/romstage.c trunk/src/mainboard/asus/m4a785-m/romstage.c trunk/src/mainboard/gigabyte/ma785gmt/romstage.c trunk/src/mainboard/gigabyte/ma78gm/romstage.c trunk/src/mainboard/hp/dl165_g6_fam10/romstage.c trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c trunk/src/mainboard/jetway/pa78vm5/romstage.c trunk/src/mainboard/msi/ms9652_fam10/romstage.c trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c trunk/src/mainboard/tyan/s2912_fam10/romstage.c Modified: trunk/src/cpu/amd/model_10xxx/Kconfig ============================================================================== --- trunk/src/cpu/amd/model_10xxx/Kconfig Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/cpu/amd/model_10xxx/Kconfig Sun Feb 27 00:29:44 2011 (r6385) @@ -50,3 +50,35 @@ endif endif + +config UPDATE_CPU_MICROCODE + bool + default y + +config UPDATE_CPU_MICROCODE + bool "Update CPU microcode" + default y + depends on EXPERT && CPU_AMD_MODEL_10XXX + help + Select this to apply patches to the CPU microcode provided by + AMD without source, and distributed with coreboot, to address + issues in the CPU post production. + + Microcode updates distributed with coreboot are not necessarily + the latest version available from AMD. Updates are only applied + if they are newer than the microcode already in your CPU. + + Unselect this to let Fam10h CPUs run with microcode as shipped + from factory. No binary microcode patches will be included in the + coreboot image in that case, which can help with creating an image + for which complete source code is available, which in turn might + simplify license compliance. + + Microcode updates intend to solve issues that have been discovered + after CPU production. The common case is that systems work as + intended with updated microcode, but we have also seen cases where + issues were solved by not applying the microcode updates. + + Note that some operating system include these same microcode + patches, so you may need to also disable microcode updates in + your operating system in order for this option to matter. Modified: trunk/src/cpu/amd/model_10xxx/Makefile.inc ============================================================================== --- trunk/src/cpu/amd/model_10xxx/Makefile.inc Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/cpu/amd/model_10xxx/Makefile.inc Sun Feb 27 00:29:44 2011 (r6385) @@ -1,5 +1,4 @@ -# no conditionals here. If you include this file from a socket, then you get all the binaries. driver-y += model_10xxx_init.c -ramstage-y += update_microcode.c +ramstage-$(CONFIG_UPDATE_CPU_MICROCODE) += update_microcode.c ramstage-y += apic_timer.c ramstage-y += processor_name.c Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c ============================================================================== --- trunk/src/cpu/amd/model_10xxx/init_cpus.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/cpu/amd/model_10xxx/init_cpus.c Sun Feb 27 00:29:44 2011 (r6385) @@ -325,7 +325,9 @@ * This happens after HTinit. * The BSP runs this code in it's own path. */ +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(cpuid_eax(1)); +#endif cpuSetAMDMSR(); #if CONFIG_SET_FIDVID Modified: trunk/src/mainboard/amd/bimini_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/amd/bimini_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/amd/bimini_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -66,7 +66,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -132,7 +136,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/amd/mahogany_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/amd/mahogany_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -66,7 +66,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include "southbridge/amd/sb700/early_setup.c" @@ -125,7 +129,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -87,7 +87,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -227,7 +231,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/amd/tilapia_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/amd/tilapia_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -65,7 +65,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -124,7 +128,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/asus/m4a78-em/romstage.c ============================================================================== --- trunk/src/mainboard/asus/m4a78-em/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/asus/m4a78-em/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -65,7 +65,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -125,7 +129,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/asus/m4a785-m/romstage.c ============================================================================== --- trunk/src/mainboard/asus/m4a785-m/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/asus/m4a785-m/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -65,7 +65,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -125,7 +129,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/gigabyte/ma785gmt/romstage.c ============================================================================== --- trunk/src/mainboard/gigabyte/ma785gmt/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/gigabyte/ma785gmt/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -61,7 +61,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -121,7 +125,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/gigabyte/ma78gm/romstage.c ============================================================================== --- trunk/src/mainboard/gigabyte/ma78gm/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/gigabyte/ma78gm/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -65,7 +65,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -123,7 +127,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/hp/dl165_g6_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/hp/dl165_g6_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/hp/dl165_g6_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -82,7 +82,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -136,7 +140,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c ============================================================================== --- trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/iei/kino-780am2-fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -67,7 +67,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -126,7 +130,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/jetway/pa78vm5/romstage.c ============================================================================== --- trunk/src/mainboard/jetway/pa78vm5/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/jetway/pa78vm5/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -72,7 +72,11 @@ #include "cpu/amd/quadcore/quadcore.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" #include <spd.h> @@ -131,7 +135,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/msi/ms9652_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/msi/ms9652_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/msi/ms9652_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -76,7 +76,11 @@ #include "southbridge/nvidia/mcp55/early_setup_car.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -153,7 +157,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -68,7 +68,11 @@ #include "southbridge/nvidia/mcp55/early_setup_car.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -145,7 +149,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -74,7 +74,11 @@ #include "southbridge/nvidia/mcp55/early_setup_car.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -197,7 +201,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR(); Modified: trunk/src/mainboard/tyan/s2912_fam10/romstage.c ============================================================================== --- trunk/src/mainboard/tyan/s2912_fam10/romstage.c Sat Feb 26 20:46:08 2011 (r6384) +++ trunk/src/mainboard/tyan/s2912_fam10/romstage.c Sun Feb 27 00:29:44 2011 (r6385) @@ -77,7 +77,11 @@ #include "southbridge/nvidia/mcp55/early_setup_car.c" #include "cpu/amd/car/post_cache_as_ram.c" #include "cpu/amd/microcode/microcode.c" + +#if CONFIG_UPDATE_CPU_MICROCODE #include "cpu/amd/model_10xxx/update_microcode.c" +#endif + #include "cpu/amd/model_10xxx/init_cpus.c" #include "northbridge/amd/amdfam10/early_ht.c" @@ -153,7 +157,9 @@ /* Setup sysinfo defaults */ set_sysinfo_in_ram(0); +#if CONFIG_UPDATE_CPU_MICROCODE update_microcode(val); +#endif post_code(0x33); cpuSetAMDMSR();

1 0

Re: [coreboot] [PATCH] Proposal for dealing with superio *.c includes
by Alex G. 26 Feb '11

26 Feb '11

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 that. :) Alex

1 0

Re: [coreboot] [PATCH] Proposal for dealing with superio *.c includes
by Alex G. 26 Feb '11

26 Feb '11

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 the road. > 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. Alex

2 1

[commit] r6384 - trunk/src/mainboard/asrock/939a785gmh
by repository service 26 Feb '11

26 Feb '11

Author: ruik Date: Sat Feb 26 20:46:08 2011 New Revision: 6384 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6384 Log: 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> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/src/mainboard/asrock/939a785gmh/mainboard.c Modified: trunk/src/mainboard/asrock/939a785gmh/mainboard.c ============================================================================== --- trunk/src/mainboard/asrock/939a785gmh/mainboard.c Sat Feb 26 19:42:04 2011 (r6383) +++ trunk/src/mainboard/asrock/939a785gmh/mainboard.c Sat Feb 26 20:46:08 2011 (r6384) @@ -35,12 +35,31 @@ void set_pcie_dereset(void); void set_pcie_reset(void); u8 is_dev3_present(void); + +static void pcie_rst_toggle(u8 val) { + u8 byte; + + byte = pm_ioread(0x8d); + byte &= ~(3 << 1); + pm_iowrite(0x8d, byte); + + byte = pm_ioread(0x94); + /* Output enable */ + byte &= ~(3 << 2); + /* Toggle GPM8, GPM9 */ + byte &= ~(3 << 0); + byte |= val; + pm_iowrite(0x94, byte); +} + void set_pcie_dereset() { + pcie_rst_toggle(0x3); } void set_pcie_reset() { + pcie_rst_toggle(0x0); } #if 0 /* not tested yet */

1 0

[PATCH] Asrock 939a785gmh - fix PCIe x16
by Rudolf Marek 26 Feb '11

26 Feb '11

Hello, 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> Thanks, Rudolf

2 1

Intel's BIOS Implementation Test Suite
by Andrew Guertin 26 Feb '11

26 Feb '11

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. http://biosbits.org/ 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. -- dolphinling <http://dolphinling.net/>

4 5

build service results for r6383
by repository service 26 Feb '11

26 Feb '11

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 changes: Change Log: 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> Build Log: 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. Best regards, coreboot automatic build system

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2011