coreboot March 2013

coreboot@coreboot.org

46 participants
782 discussions

Patch merged into coreboot/master: 45f72ce AMD Persimmon: Use SPD read code from F14 wrapper
by gerrit＠coreboot.org 07 Mar '13

07 Mar '13

the following patch was just integrated into master: commit 45f72ce60f41a655514c29698678cf3c1fb0c1a9 Author: Martin Roth <martin.roth(a)se-eng.com> Date: Sun Feb 24 12:58:33 2013 -0700 AMD Persimmon: Use SPD read code from F14 wrapper Changes: - Get rid of the persimmon mainboard specific code which has been moved into the wrapper as a platform generic function in change http://review.coreboot.org/#/c/2497/ AMD f14: Add SPD read functions to wrapper code - Move DIMM addresses into devicetree.cb - Add the ASF init that used to be in the SPD read code into mainboard_enable() Notes: - The DIMM reads only happen in romstage, so the function is not available in ramstage. Point the read-SPD callback to a generic function in ramstage. Change-Id: I5f017dbb8dee5a09ec19734a6069ff9b71a6ab50 Signed-off-by: Martin Roth <martin.roth(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2500 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Reviewed-by: Jens Rottmann <JRottmann(a)LiPPERTembedded.de> Reviewed-by: Marc Jones <marc.jones(a)se-eng.com> Build-Tested: build bot (Jenkins) at Mon Mar 4 23:54:16 2013, giving +1 Reviewed-By: Marc Jones <marc.jones(a)se-eng.com> at Thu Mar 7 00:37:25 2013, giving +2 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Tue Mar 5 01:17:08 2013, giving +1 See http://review.coreboot.org/2500 for details. -gerrit

1 0

Patch merged into coreboot/master: 3b2653b AMD Fam14: Add SPD read functions to wrapper code
by gerrit＠coreboot.org 07 Mar '13

07 Mar '13

the following patch was just integrated into master: commit 3b2653b1fc207111e96585a273294cedffc49141 Author: Martin Roth <martin.roth(a)se-eng.com> Date: Sun Feb 24 10:46:11 2013 -0700 AMD Fam14: Add SPD read functions to wrapper code Change: This is the initial step for moving the AMD F14 & HUDSON1,2,3 SPD-read callout out of the mainboard directories and into the wrapper. The next step is to update the platforms to use this routine in BiosCallouts.c and to delete the code from the mainboard directories. The DIMM addresses should be moved into devicetree.cb. If there are significant differences or reasons that the mainboard needs to override this code, it's perfectly reasonable to keep using the version in the mainboard, but this allows us to remove duplicated code and simplify the mainboard directories. Notes: This started by duplicating what was in Persimmon, and was changed to use the devicetree.cb structures. The ASF setup was also removed from the persimmon copy (PMIO writes to 0x28 & 0x29) as that's not needed for the SPD access and doesn't make sense to initialize here. Significant cleanup and magic number reduction was done as well. It is intended that this file will not be included in ramstage as the DIMM init is all done in romstage. This is similar to what was done for Parmer/Thatcher in commit 7fb692bd - http://review.coreboot.org/#/c/2190/ Fam15tn: Move SPD read from mainboards into wrapper Yes, it would make sense to split this into two separate files and move the SMBUS initialization and access into the southbridge wrapper. Maybe that can come next. Change-Id: I1e106d3912c160b0015bf02158d9faba4f578ee3 Signed-off-by: Martin Roth <martin.roth(a)se-eng.com> Reviewed-on: http://review.coreboot.org/2497 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Reviewed-by: Jens Rottmann <JRottmann(a)LiPPERTembedded.de> Reviewed-by: Marc Jones <marc.jones(a)se-eng.com> Build-Tested: build bot (Jenkins) at Tue Mar 5 00:04:05 2013, giving +1 Reviewed-By: Marc Jones <marc.jones(a)se-eng.com> at Thu Mar 7 00:39:19 2013, giving +2 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Tue Mar 5 01:17:58 2013, giving +1 See http://review.coreboot.org/2497 for details. -gerrit

1 0

Patch merged into coreboot/master: be738eb Remove UTF-8 characters from comments
by gerrit＠coreboot.org 07 Mar '13

07 Mar '13

the following patch was just integrated into master: commit be738eb1336a856bc6f2494ccd7ede3194e6c618 Author: Ronald G. Minnich <rminnich(a)gmail.com> Date: Thu Mar 7 11:05:28 2013 -0600 Remove UTF-8 characters from comments I've used an operating system for over 10 years now that makes UTF-8 easy. It's not called Linux or OSX. When UTF-8 is needed, of course, then we can look again. I can't think of a single redeeming feature of placing it in the comment in this manner. It's certainy not needed. The inclusion of UTF-8 characters is inconvenient, especially from a text terminal. I don't really want to start using compose in CROSH shell terminals on chromeos. We might want to incorporate "no UTF-8" as a commit filter. For now, get rid of these characters. Change-Id: If94cc657bae1dbd282bec8de6c5309b1f8da5659 Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Reviewed-on: http://review.coreboot.org/2604 Reviewed-by: Bernhard Urban <lewurm(a)gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter(a)users.sourceforge.net> Build-Tested: build bot (Jenkins) at Thu Mar 7 18:19:18 2013, giving +1 See http://review.coreboot.org/2604 for details. -gerrit

1 0

New patch to review for coreboot: a7b2d85 Remove UTF-8 characters from comments
by Ronald G. Minnich 07 Mar '13

07 Mar '13

Ronald G. Minnich (rminnich(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2604 -gerrit commit a7b2d85f2ebc6b3c30513502159fd51fbf6e3253 Author: Ronald G. Minnich <rminnich(a)gmail.com> Date: Thu Mar 7 11:05:28 2013 -0600 Remove UTF-8 characters from comments I've used an operating system for over 10 years now that makes UTF-8 easy. It's not called Linux or OSX. When UTF-8 is needed, of course, then we can look again. I can't think of a single redeeming feature of placing it in the comment in this manner. It's certainy not needed. The inclusion of UTF-8 characters is inconvenient, especially from a text terminal. I don't really want to start using compose in CROSH shell terminals on chromeos. We might want to incorporate "no UTF-8" as a commit filter. For now, get rid of these characters. Change-Id: If94cc657bae1dbd282bec8de6c5309b1f8da5659 Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- src/arch/x86/boot/acpigen.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/arch/x86/boot/acpigen.c b/src/arch/x86/boot/acpigen.c index 58e783e..121cb22 100644 --- a/src/arch/x86/boot/acpigen.c +++ b/src/arch/x86/boot/acpigen.c @@ -211,13 +211,13 @@ int acpigen_emit_namestring(const char *namepath) { int dotpos = 0; int len = 0; - /* We can start with a »\«. */ + /* We can start with a '\'. */ if (namepath[0] == '\\') { len += acpigen_emit_byte('\\'); namepath++; } - /* And there can be any number of »^«. */ + /* And there can be any number of '^' */ while (namepath[0] == '^') { len += acpigen_emit_byte('^'); namepath++;

1 0

Patch set updated for coreboot: 2b9f9b5 Fam14 DSDT: Add secondary bus range to PCI0
by Paul Menzel 07 Mar '13

07 Mar '13

Paul Menzel (paulepanter(a)users.sourceforge.net) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2592 -gerrit commit 2b9f9b55bbb33ead7ed60d152f250dba3b5c383f Author: Mike Loptien <mike.loptien(a)se-eng.com> Date: Tue Mar 5 14:21:28 2013 -0700 Fam14 DSDT: Add secondary bus range to PCI0 Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number for the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. Change-Id: I44f22bc03a0dcbcd2594d4291508826cc2146860 Signed-off-by: Mike Loptien <mike.loptien(a)se-eng.com> Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> --- src/mainboard/amd/persimmon/dsdt.asl | 9 +++++++++ src/mainboard/asrock/e350m1/dsdt.asl | 9 +++++++++ src/mainboard/lippert/frontrunner-af/dsdt.asl | 10 ++++++++++ 3 files changed, 28 insertions(+) diff --git a/src/mainboard/amd/persimmon/dsdt.asl b/src/mainboard/amd/persimmon/dsdt.asl index 582ab7f..8cf86eb 100644 --- a/src/mainboard/amd/persimmon/dsdt.asl +++ b/src/mainboard/amd/persimmon/dsdt.asl @@ -1477,6 +1477,15 @@ DefinitionBlock ( } /* end Ac97modem */ Name(CRES, ResourceTemplate() { + /* Set the bus number and secondary bus number for the PCI0 device. */ + WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, + 0x0000, /* address granularity */ + 0x0000, /* range minimum */ + 0x00FE, /* range maximum */ + 0x0000, /* translation */ + 0x00FF, /* length */ + ,, PSB0) /* ResourceSourceIndex, ResourceSource, DescriptorName */ + IO(Decode16, 0x0CF8, 0x0CF8, 1, 8) WORDIO(ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, diff --git a/src/mainboard/asrock/e350m1/dsdt.asl b/src/mainboard/asrock/e350m1/dsdt.asl index bc45435..570e7c4 100644 --- a/src/mainboard/asrock/e350m1/dsdt.asl +++ b/src/mainboard/asrock/e350m1/dsdt.asl @@ -1477,6 +1477,15 @@ DefinitionBlock ( } /* end Ac97modem */ Name(CRES, ResourceTemplate() { + /* Set the bus number and secondary bus number for the PCI0 device. */ + WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, + 0x0000, /* address granularity */ + 0x0000, /* range minimum */ + 0x00FE, /* range maximum */ + 0x0000, /* translation */ + 0x00FF, /* length */ + ,, PSB0) /* ResourceSourceIndex, ResourceSource, DescriptorName */ + IO(Decode16, 0x0CF8, 0x0CF8, 1, 8) WORDIO(ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, diff --git a/src/mainboard/lippert/frontrunner-af/dsdt.asl b/src/mainboard/lippert/frontrunner-af/dsdt.asl index d3b88f7..599c32f 100644 --- a/src/mainboard/lippert/frontrunner-af/dsdt.asl +++ b/src/mainboard/lippert/frontrunner-af/dsdt.asl @@ -1480,6 +1480,16 @@ DefinitionBlock ( Name(CRES, ResourceTemplate() { IO(Decode16, 0x004E, 0x004E, 1, 2) /* SIO config regs */ IO(Decode16, 0x0E00, 0x0E00, 1, 0x80) /* SIO runtime regs */ + + /* Set the bus number and secondary bus number for the PCI0 device. */ + WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, + 0x0000, /* address granularity */ + 0x0000, /* range minimum */ + 0x00FE, /* range maximum */ + 0x0000, /* translation */ + 0x00FF, /* length */ + ,, PSB0) /* ResourceSourceIndex, ResourceSource, DescriptorName */ + IO(Decode16, 0x0CF8, 0x0CF8, 1, 8) WORDIO(ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,

1 0

[SeaBIOS] [SimNow] PORT_IRQ_STAT register is 0 in ahci_port_setup
by WANG Siyuan 07 Mar '13

07 Mar '13

Hi, I am trying to boot a hard disk image using coreboot and seabios on SimNow Simulator. The system stops at seabios stage. PORT_CMD_START fails in function ahci_port_setup (seabios/src/ahci.c), Then I traced into function ahci_command (seabios/src/ahci.c), I found the value of register ORT_IRQ_STAT is always 0: intbits = ahci_port_readl(ctrl, pnr, PORT_IRQ_STAT); intbits returns 0 all the time, so system stops here until time out. Any comments would be appreciated. -- Yours sincerely, WANG Siyuan

1 0

Re: [coreboot] [RFC] Keep all Jenkins build logs
by Patrick Georgi 07 Mar '13

07 Mar '13

Am 2013-03-07 07:10, schrieb Gregg Levine: > Ron, he's right. I just checked and it seems that everything including > that number is not at home. Perhaps there's a finite limit to how many > records the bot can work with? It's limited because build logs get large quickly and we ran out of disk space a couple of times. After each of these issues I reduced the historical log some more. So yes, Paul's right that old logs are gone. Like Ron I'm not convinced that they add any value after their current life-time (3 weeks or 50 commits, whichever comes first - or something like that). Patrick

1 0

Re: [coreboot] [RFC] Keep all Jenkins build logs
by Gregg Levine 07 Mar '13

07 Mar '13

On Thu, Mar 7, 2013 at 12:38 AM, ron minnich <rminnich(a)gmail.com> wrote: > I'm not convinced. > > ron > > On Wed, Mar 6, 2013 at 9:48 AM, Paul Menzel > <paulepanter(a)users.sourceforge.net> wrote: >> Dear coreboot folks, >> >> >> Jenkins seems to be configured to delete build logs after a certain >> amount of time. For example #4000 is not there anymore [1]. >> >> I am aware that Jenkins has to build a lot of commits (and their >> iterations). For archival purposes, I’d vote for keeping the logs, if >> possible. For example to find out if certain warnings have existed >> already without having to rebuild locally. >> >> With big hard drives and compression that should be doable, right? >> >> >> Thanks, >> >> Paul >> >> >> [1] http://qa.coreboot.org/job/coreboot-gerrit/4000/ >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot Hello! Ron, he's right. I just checked and it seems that everything including that number is not at home. Perhaps there's a finite limit to how many records the bot can work with? ----- Gregg C Levine gregg.drwho8(a)gmail.com "This signature fought the Time Wars, time and again."

1 0

Makefiles question: -fno-delete-null-pointer-checks needed in Makefiles
by Jens Rottmann 07 Mar '13

07 Mar '13

Hi Martin (and all), I wrote: >> You dereference dev in line 132, so if it's really 0, >> will you then ever reach this check?? (I don't know if >> in romstage *NULL is caught.) You wrote: > yes, if it's 0, we still reach the code. I've changed it > to not dereference it before checking it though. Per default, after any *ptr, GCC assumes a SEGFAULT would occur if ptr was ==0, so if control flow does reach the following code ptr must be !=0. ==> After any *ptr GCC will optimize away all ptr==0 or !=0 checks. I know that because I recently hunted a related bug for a week (U-Boot, ARM, different project) until I looked at the actual assembly code. Are you sure romstage (or maybe even ramstage?) will *NULL without segfaulting and just continue? And is romstage compiled with GCC (+ CAR) or is romcc used? In that case "-fno-delete-null-pointer-checks" must be added to the GCC options. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html I greped a bit, looks like it's not in any Makefiles yet. Could someone who knows Coreboot's make/build system better than me maybe help, please? Thanks Jens

4 3

Patch merged into coreboot/master: 147cdc3 Revert "ARMv7: Simplify div64"
by gerrit＠coreboot.org 07 Mar '13

07 Mar '13

the following patch was just integrated into master: commit 147cdc3b171c8f02434dc3b6bbd70b6406de93ee Author: David Hendricks <dhendrix(a)chromium.org> Date: Thu Mar 7 00:58:10 2013 +0100 Revert "ARMv7: Simplify div64" This reverts commit 1cd616082100f47dc2d6d73669c6aa2e5eb039ad Division bites us again. I don't know how or why, but printk() seems to break (again) with this patch. I'm surprised we didn't encounter problems earlier on... Change-Id: I81cb9f20879f5eb73a76e1af47b96a68d1e81dc8 TODO: Find a better solution for div64. This one is too painful, but seems necessary for now (and sort-of works with our vtxprintf hack). Reviewed-on: http://review.coreboot.org/2600 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Thu Mar 7 01:09:33 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Thu Mar 7 06:45:38 2013, giving +2 See http://review.coreboot.org/2600 for details. -gerrit

1 0

← Newer
1
...
64
65
66
67
68
69
70
...
79
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 March 2013