coreboot February 2009

coreboot@coreboot.org

67 participants
232 discussions

Re: [coreboot] r3945 - in trunk/coreboot-v2: src/mainboard targets
by Carl-Daniel Hailfinger 13 Feb '09

13 Feb '09

On 13.02.2009 21:20, svn(a)coreboot.org wrote: > Author: rminnich > Date: 2009-02-13 21:20:21 +0100 (Fri, 13 Feb 2009) > New Revision: 3945 > > Removed: > trunk/coreboot-v2/src/mainboard/agami/ > trunk/coreboot-v2/targets/agami/ > Log: > This target is dead. > > The company is dead. > > It causes builds to fail, and that is not a problem we need to have. > > Removing it to remove the problems it causes. > > Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> > Acked-by: Stefan Reinauer <stepan(a)coresystems.de> > Why? I had fixed the target in r3944. Anyway, the code is still in the tree history, so I won't complain too loudly. Do we want to keep a list of removed boards together with the last working revision? Oh, and can someone please update the wiki with the info that r3944 is the last working revision for the Agami Aruma? Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

r3945 - in trunk/coreboot-v2: src/mainboard targets
by svn＠coreboot.org 13 Feb '09

13 Feb '09

Author: rminnich Date: 2009-02-13 21:20:21 +0100 (Fri, 13 Feb 2009) New Revision: 3945 Removed: trunk/coreboot-v2/src/mainboard/agami/ trunk/coreboot-v2/targets/agami/ Log: This target is dead. The company is dead. It causes builds to fail, and that is not a problem we need to have. Removing it to remove the problems it causes. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de>

1 0

[RFC] More generic targets with C preprocessor token concatenation
by Carl-Daniel Hailfinger 13 Feb '09

13 Feb '09

Hi, all boards have various variables named mainboard_$VENDOR_$PARTNUMBER_config and similar. If you run diff between related targets, these variables often account for a sizable chunk of the diff. That means for every new target we have to run a search/replace operation even if the file contents (except variable names) do not change. I think these search/replace operations are an unnecessary complication during porting and should be eliminated because they require a human to deal with the quirks of our build tools. Below is a patch example which _should_ remove this type problem. --- src/mainboard/amd/dbm690t/chip.h (revision 3943) +++ src/mainboard/amd/dbm690t/chip.h (working copy) @@ -19,7 +19,7 @@ extern struct chip_operations mainboard_amd_dbm690t_ops; -struct mainboard_amd_dbm690t_config +struct mainboard_##MAINBOARD_VENDOR##_##MAINBOARD_PART_NUMBER##_config { u32 uma_size; /* How many UMA should be used in memory for TOP. */ }; I wrote "should" because that patch does not work. MAINBOARD_VENDOR and MAINBOARD_PART_NUMBER are defined as strings with double quotes. Concatenating strings with variable names can't work. To fix this, I need an additional #define with mainboard vendor and part number and that #define should not be a string. Suggestion: #define MAINBOARD_PREFIX mainboard_amd_dbm690t Of course, that #define would be generated as a gcc parameter by our config tools (like MAINBOARD_VENDOR). With that change in the config tools, the patch above would look like this: --- src/mainboard/amd/dbm690t/chip.h (revision 3943) +++ src/mainboard/amd/dbm690t/chip.h (working copy) @@ -19,7 +19,7 @@ extern struct chip_operations mainboard_amd_dbm690t_ops; -struct mainboard_amd_dbm690t_config +struct MAINBOARD_PREFIX##_config { u32 uma_size; /* How many UMA should be used in memory for TOP. */ }; What do you think? Regards, Carl-Daniel -- http://www.hailfinger.org/

4 11

r3944 build service
by coreboot information 13 Feb '09

13 Feb '09

Dear coreboot readers! This is the automated build check service of coreboot. The developer "hailfinger" checked in revision 3944 to the coreboot source repository and caused the following changes: Change Log: Increase ROM_IMAGE_SIZE for the agami aruma to resolve overlapping sections. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Build Log: Compilation of agami:aruma has been fixed Compilation of amd:dbm690t is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3944&device=dbm690t&vendor… Compilation of amd:pistachio is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3944&device=pistachio&vend… If something broke during this checkin please be a pain in hailfinger'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

r3942 build service
by coreboot information 13 Feb '09

13 Feb '09

Dear coreboot readers! This is the automated build check service of coreboot. The developer "stepan" checked in revision 3942 to the coreboot source repository and caused the following changes: Change Log: Fix mtrr setup for UMA architectures. If high SMM memory is used (and needs to be uncached for whatever reason; it shouldn't in my opinion), we should do it the same way. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Peter Stuge <peter(a)stuge.se> Build Log: Compilation of agami:aruma has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3942&device=aruma&vendor=a… Compilation of amd:dbm690t has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3942&device=dbm690t&vendor… Compilation of amd:pistachio has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3942&device=pistachio&vend… If something broke during this checkin please be a pain in stepan'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

2 1

r3944 - trunk/coreboot-v2/targets/agami/aruma
by svn＠coreboot.org 13 Feb '09

13 Feb '09

Author: hailfinger Date: 2009-02-13 19:46:22 +0100 (Fri, 13 Feb 2009) New Revision: 3944 Modified: trunk/coreboot-v2/targets/agami/aruma/Config-abuild.lb Log: Increase ROM_IMAGE_SIZE for the agami aruma to resolve overlapping sections. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/targets/agami/aruma/Config-abuild.lb =================================================================== --- trunk/coreboot-v2/targets/agami/aruma/Config-abuild.lb 2009-02-12 21:30:06 UTC (rev 3943) +++ trunk/coreboot-v2/targets/agami/aruma/Config-abuild.lb 2009-02-13 18:46:22 UTC (rev 3944) @@ -17,7 +17,7 @@ romimage "fallback" option USE_FALLBACK_IMAGE=1 - option ROM_IMAGE_SIZE=0x16000 + option ROM_IMAGE_SIZE=0x16100 option XIP_ROM_SIZE=0x20000 option COREBOOT_EXTRA_VERSION=".0-fallback" payload __PAYLOAD__

1 0

Obvious bug in mcp55/pci.c
by Ronald Hoogenboom 13 Feb '09

13 Feb '09

Hi, I stumbled on an obvious error in a piece of code (v3) conditional on CONFIG_PCI_64BIT_PREF_MEM. What is the exact purpose of this config and why is it obviously never used? (doesn't even compile)

3 4

r1132 - coreboot-v3/southbridge/nvidia/mcp55
by svn＠coreboot.org 13 Feb '09

13 Feb '09

Author: hailfinger Date: 2009-02-13 12:00:21 +0100 (Fri, 13 Feb 2009) New Revision: 1132 Modified: coreboot-v3/southbridge/nvidia/mcp55/pci.c Log: Fix missing indirection for CONFIG_PCI_64BIT_PREF_MEM. That config still does not compile, but this needed fixing anyway. Signed-off-by: Ronald Hoogenboom <hoogenboom30(a)zonnet.nl> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: coreboot-v3/southbridge/nvidia/mcp55/pci.c =================================================================== --- coreboot-v3/southbridge/nvidia/mcp55/pci.c 2009-02-12 21:15:34 UTC (rev 1131) +++ coreboot-v3/southbridge/nvidia/mcp55/pci.c 2009-02-13 11:00:21 UTC (rev 1132) @@ -38,7 +38,7 @@ u32 dword; u16 word; #ifdef CONFIG_PCI_64BIT_PREF_MEM - struct device pci_domain_dev; + struct device *pci_domain_dev; struct resource *mem1, *mem2; #endif

1 0

[v3] r1129 makes bootblock too big
by Ronald Hoogenboom 13 Feb '09

13 Feb '09

Hi, After updating to r1129, adds call to allow_all_aps_stop to initram.c, bootblock is too big (16 bytes) and build fails. (gigabyte m57sli) Ronald.

4 9

r3943 build service
by coreboot information 12 Feb '09

12 Feb '09

Dear coreboot readers! This is the automated build check service of coreboot. The developer "myles" checked in revision 3943 to the coreboot source repository and caused the following changes: Change Log: This patch converts __FUNCTION__ to __func__, since __func__ is standard. Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Build Log: Compilation of agami:aruma is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3943&device=aruma&vendor=a… Compilation of amd:dbm690t is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3943&device=dbm690t&vendor… Compilation of amd:pistachio is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3943&device=pistachio&vend… If something broke during this checkin please be a pain in myles'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
...
12
13
14
15
16
17
18
...
24
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 2009