coreboot February 2011

coreboot@coreboot.org

52 participants
283 discussions

[PATCH v3] Lenovo X60s Support
by Sven Schnelle 14 Feb '11

14 Feb '11

Hi List, this patch adds support for Lenovo X60s (Model 1703) Thinkpads. It is a basic Patch without SMI and ACPI, as this makes it probably easier to review. I'll send SMI and ACPI Patches as soon as the patch is commited. Signed-off-by: Sven Schnelle <svens(a)stackframe.org>

1 0

Unused files
by Stefan Reinauer 14 Feb '11

14 Feb '11

These include files are unused, they are never included src/cpu/amd/model_10xxx/mc_patch_01000020.h src/cpu/amd/model_10xxx/mc_patch_01000083.h src/cpu/amd/model_10xxx/mc_patch_01000084.h src/cpu/intel/model_f1x/multiplier.h src/cpu/intel/model_f0x/multiplier.h src/southbridge/amd/cs5536/smbus2.h I vote for dropping them. Stefan

4 5

Re: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 1 of 8.
by Scott Duplichan 14 Feb '11

14 Feb '11

]From: coreboot-bounces+scott=notabs.org(a)coreboot.org [mailto:coreboot-]bounces+scott=notabs.org@coreboot.org] On Behalf Of Vibrans, Frank ]Sent: Sunday, February 13, 2011 03:43 PM ]To: coreboot(a)coreboot.org ]Subject: [coreboot] AMD Agesa and AMD CIMx SB800 code. Patch 1 of 8. ] ]Add AMD Agesa and AMD CIMx SB800 code. Patch 1 of 8. ] ]This code currently generates many warnings that are functionally benign. These are ]being addressed, but the wheels of bureaucracy turn slowly. This drop supports AMD ]cpu families 10h and 14h. Only Family 14h is used as an example in this set of ]patches. Other cpu families are supported by the infrastructure, but their specific ]support is not included herein. This patch is functionally independent of the other ]patches in this set. ] ]Signed-off-by Frank Vibrans <frank.vibrans(a)amd.com> ] ]-- ] ]This patch is compressed because when it expands, it is 11.3 MB or so. Wow, thanks a lot Frank and AMD folks. I will be satisfied to suppress the warnings for this part of the build, knowing the code is already well proven. This is quite a milestone for coreboot. Now half of the major processor vendors support coreboot for their current products. Thanks, Scott

1 0

question: Is it possible for OS to initialize the memory
by Fengwei Zhang 13 Feb '11

13 Feb '11

Hi all, recently, I am using coreboot for my project. I have two DIMM slots on my board and I installed two memory modules on it(each DIMM slot has a memory module). Currently, I let coreboot initialize one of them. After loading operating system, I would like to use OS to initialize another memory module. my question is: Is it feasible for OS to initialize the another memory module? I looked at the BKDG of my board, I didn't see any documented words saying I can do or cannot do this. I would appreciate it if anyone could give me some hints or direction of what documents I need to look at. Thanks, Fengwei

2 1

pygen: code generation from xml files. step 1: msrtool module - fixes
by Антон Кочков 13 Feb '11

13 Feb '11

msrtool: add support for code generation from xml files Search all *.msr.xml files in directory, creating *.c files from them, produce *.patch for msrtool.c and msrtool.h Signed-off-by: Anton Kochkov <anton.kochkov(a)gmail.com> --- Small fixes, included export_msr.c file, which produce *.msr.xml files from existing code

1 0

Now that I swapped in my other P2B-LS, I finally found out a few things
by Keith Hui 13 Feb '11

13 Feb '11

I have two P2B-LS mainboards. I have been doing development on a newer rev 1.04 "Dot" board while my desktop runs a rev 1.03 board heavily modified by myself [1]. It's my "Trophy" at my high times in modding things. Tonight I swapped my two P2B-LS boards so I can try coreboot on Trophy. I know 1.04. has Winbond 83977EF for superio. Found out 1.03 has W83977TF. The reason why SCSI isn't enabled properly is because my 1.04. actually has broken Ultra2 SCSI hardware. I have to put my drives on the single-ended ultra-wide port for them to be detected at all. And I don't think it's a termination problem. Is it possible that my previous attempts at getting the SCSI bios to load fry the hardware? Now I need to bring in serialice to find out how the onboard termination is controlled. Once I figured out how to control this termination, where should I put code to control this? A driver like Sil3114 or add to the board level romstage? I should update the wiki with my findings.

1 0

pygen: code generation from xml files. step 1: msrtool module
by Антон Кочков 13 Feb '11

13 Feb '11

1 0

msrtool: add support for code generation from xml files. step 2
by Антон Кочков 12 Feb '11

12 Feb '11

1 0

#173: Build faiulre with gcc 4.4.3 because of src/pc80/mc146818rtc_early.c unused variable
by coreboot 12 Feb '11

12 Feb '11

#173: Build faiulre with gcc 4.4.3 because of src/pc80/mc146818rtc_early.c unused variable --------------------------+-------------------------------------- Reporter: anonymous | Owner: stepan@… Type: defect | Status: new Priority: major | Milestone: Component: coreboot | Keywords: Dependencies: | Patch Status: there is no patch --------------------------+-------------------------------------- Hello, I'm trying to build coreboot with SeaBIOS payload for a qemu x86 platform, just to give it a try. I've selected the "Use CMOS for configuration values" option in the General setup menu just as a try (I don't know if that option is supported by qemu, nor if that's related with my problem anyway, this is my very first attempt playing around with coreboot) and my build process stopped with the following error: [[BR]] {{{ cc1: warnings being treated as errors[[BR]] src/pc80/mc146818rtc_early.c: In function 'do_normal_boot': src/pc80/mc146818rtc_early.c:64: error: unused variable 'i' make: *** [build/pc80/mc146818rtc_early.romstage.o] Error 1 }}} [[BR]] As stated in this ticket summary, I'm using gcc 4.4.3; I'm also building the stable version of coreboot, retrieved with the command: [[BR]] {{{ svn co svn://coreboot.org/coreboot/trunk coreboot }}} [[BR]] A closer look to the source file showed me that variable 'i' is only used within a conditionally compiled block, so I've solved the problem by simply wrapping that variable declaration in a similar '#if' block as follows: [[BR]] {{{ static inline int do_normal_boot(void) { unsigned char byte; #if CONFIG_USE_CMOS_RECOVERY int i; #endif }}} [[BR]] (i could just be moved entirely within the conditional block, according to coding style preferences) [[BR]] Though, I don't know if the above really solves the problem (in case, for instance, 'CONFIG_USE_CMOS_RECOVERY' should be defined in my configuration or in general), so that might require some further investigation by developers actively working on that piece of code (and aware of all internals). I'm not sure what kind of priority should be given to this ticket, thus I'm leaving the default (major) for you to set it more appropriately, hoping you won't be disappointed about this. Regards. -- Ticket URL: <https://tracker.coreboot.org/trac/coreboot/ticket/173> coreboot <http://www.coreboot.org/>

1 2

msrtool: add support for code generation from xml files
by Антон Кочков 12 Feb '11

12 Feb '11

msrtool: add support for Intel Signed-off-by: Anton Kochkov <anton.kochkov(a)gmail.com> ---

1 1

← Newer
1
...
18
19
20
21
22
23
24
...
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