coreboot March 2013

coreboot@coreboot.org

46 participants
782 discussions

Patch merged into coreboot/master: 3bf0ce7 rmodule: add 16 bytes of padding
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 3bf0ce79b91a432344c42287b22a7704561ab68e Author: Aaron Durbin <adurbin(a)chromium.org> Date: Wed Feb 6 12:47:26 2013 -0600 rmodule: add 16 bytes of padding There is a plan to utlize rmodules for loading ramstage as a relocatable module. However, the rmodule header may change. In order to provide some wiggle room for changing the contents of the rmodule header add some padding. This won't stop the need for coordinating properly between the romstage loader that may be in readonly flash and rmodule header fields. But it will provide for a way to make certain assumptions about alignment of the rmodule's program when the rmodule is compressed in the flash. Change-Id: I9ac5cf495c0bce494e7eaa3bd2f2bd39889b4c52 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2749 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 23:46:05 2013, giving +1 See http://review.coreboot.org/2749 for details. -gerrit

1 0

Patch merged into coreboot/master: 8e345d4 haswell: lapic timer support
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 8e345d4ca2a13ebdf9edf1071d7c4f03d084d143 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Tue Jan 15 15:34:08 2013 -0600 haswell: lapic timer support Haswell's BCLK is fised at 100MHz like Sandy/Ivy. Add Haswell's model to the switch statement. Change-Id: Ib9e2afc04eba940bfcee92a6ee5402759b21cc45 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2747 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 23:24:27 2013, giving +1 See http://review.coreboot.org/2747 for details. -gerrit

1 0

Patch merged into coreboot/master: 18af4d2 lynxpoint: Move a bit of generic RCBA into early_pch
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 18af4d23f6b17827dda50d17d8dc9da5b2656eef Author: Duncan Laurie <dlaurie(a)chromium.org> Date: Wed Dec 19 13:17:06 2012 -0800 lynxpoint: Move a bit of generic RCBA into early_pch Rather than have to repeat this bit in every mainboard. Also, remove the reset of the RTC power status from here. We had done this in TOT for current platforms but did not carry it back to emeraldlake2 where this branched from. If we clear the status here then we don't get an event logged later which can be important for the devices that do not have a CMOS battery. Change-Id: Ia7131e9d9e7cf86228a285df652a96bcabf05260 Signed-off-by: Duncan Laurie <dlaurie(a)chromium.org> Reviewed-on: http://review.coreboot.org/2683 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Thu Mar 14 23:02:55 2013, giving +1 See http://review.coreboot.org/2683 for details. -gerrit

1 0

Patch merged into coreboot/master: ad93552 lib: add rmodule support
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit ad93552b86579afd29e99da1b2fcacb0d872cd1a Author: Aaron Durbin <adurbin(a)chromium.org> Date: Mon Dec 24 14:28:37 2012 -0600 lib: add rmodule support A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2692 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 21:37:54 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Mon Mar 18 18:40:34 2013, giving +2 See http://review.coreboot.org/2692 for details. -gerrit

1 0

Patch set updated for coreboot: 4bc5005 samsung/exynos5: add resource functions for the display port
by Ronald G. Minnich 18 Mar '13

18 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/2615 -gerrit commit 4bc5005618d0cd05a82d7f74464b34ba2dc87201 Author: Ronald G. Minnich <rminnich(a)gmail.com> Date: Mon Mar 18 09:49:54 2013 -0700 samsung/exynos5: add resource functions for the display port Not working, seemingly, but we need to add a 4M resource for memory, and it seems it needs to be fixed at the address shown. This address was chosen from current hardware. The pnp device in the displayport is really hokey. We're going to have to create a new kind of device, maybe called 'hardwired', or something, to allow us to wire down devices we know are there without probing. Discussion on IRC implies this is the direction we need to go. Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> --- .../exynos5-common/displayport/displayport.c | 41 +++++++++++++++++--- src/mainboard/google/snow/devicetree.cb | 45 ++++++++++++---------- 2 files changed, 60 insertions(+), 26 deletions(-) diff --git a/src/cpu/samsung/exynos5-common/displayport/displayport.c b/src/cpu/samsung/exynos5-common/displayport/displayport.c index 1c08bc7..1da339b 100644 --- a/src/cpu/samsung/exynos5-common/displayport/displayport.c +++ b/src/cpu/samsung/exynos5-common/displayport/displayport.c @@ -19,6 +19,7 @@ #include <stdlib.h> #include <string.h> +#include <stddef.h> #include <delay.h> #include <arch/io.h> #include <device/device.h> @@ -83,22 +84,52 @@ static void exynos_displayport_init(void) #endif } -static void exynos_displayport_noop(device_t dummy) +static void exynos_displayport_read_resources(device_t dev) { + struct cpu_samsung_exynos5_common_displayport_config *conf = dev->chip_info; + struct resource *resource; + printk(BIOS_SPEW, "%s: dev %p\n", __func__, dev); + /* claim a resource for the UMA graphics. + * Follow the current convention of starting at 24M + * from the start. + */ + resource = new_resource(dev, 0); + /* this is a hardcode for now. There's some real confusion about what it + * needs to be, docs are not helping, and hardware on real systems + * has settings we don't understand. FIXME. + */ + resource->base = 0x20000000 + 24*MiB; + resource->size = conf->xres * conf->yres * 4; /* 4 bytes per pixel for RGB */ + resource->flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED; + printk(BIOS_DEBUG, "Adding graphics at %p, size %08lx\n", (void *)resource->base, resource->size); +} + +static void exynos_displayport_set_resources(device_t dev) +{ + printk(BIOS_SPEW, "%s: dev %p\n", __function__, dev); +} + +static void exynos_displayport_enable_resources(device_t dev) +{ + printk(BIOS_SPEW, "%s: dev %p\n", __function__, dev); } static struct device_operations exynos_displayport_operations = { - .read_resources = exynos_displayport_noop, - .set_resources = exynos_displayport_noop, - .enable_resources = exynos_displayport_noop, + .read_resources = exynos_displayport_read_resources, + .set_resources = exynos_displayport_set_resources, + .enable_resources = exynos_displayport_enable_resources, .init = exynos_displayport_init, .scan_bus = exynos_displayport_noop, }; static void exynos_displayport_enable(struct device *dev) { - if (dev->link_list != NULL) + printk(BIOS_SPEW, "%s: ", __function__); + if (dev->link_list != NULL){ + printk(BIOS_SPEW, "set ops"); dev->ops = &exynos_displayport_operations; + } + printk(BIOS_SPEW, "\n"); } struct chip_operations drivers_i2c_exynos_displayport_ops = { diff --git a/src/mainboard/google/snow/devicetree.cb b/src/mainboard/google/snow/devicetree.cb index 5ad786e..b48ae97 100644 --- a/src/mainboard/google/snow/devicetree.cb +++ b/src/mainboard/google/snow/devicetree.cb @@ -20,27 +20,30 @@ # FIXME: this is just a stub for now chip cpu/samsung/exynos5250 -device cpu_cluster 0 on -end + device cpu_cluster 0 on + + device domain 0 on + chip drivers/generic/generic # I2C0 controller + device i2c 6 on end # ? + device i2c 9 on end # ? + end + chip cpu/samsung/exynos5-common/displayport + device pnp 0 on end + register "xres" = "1366" + register "yres" = "768" + register "bpp" = "16" + # complex magic timing! + register "clkval_f" = "2" + register "upper_margin" = "14" + register "lower_margin" = "3" + register "vsync" = "5" + register "left_margin" = "80" + register "right_margin" = "48" + register "hsync" = "32" + register "lcdbase" = "0x10000000" + end + end -device domain 0 on - chip drivers/generic/generic # I2C0 controller - device i2c 6 on end # ? - device i2c 9 on end # ? - end - chip cpu/samsung/exynos5-common/displayport - register "xres" = "1366" - register "yres" = "768" - register "bpp" = "16" - # complex magic timing! - register "clkval_f" = "2" - register "upper_margin" = "14" - register "lower_margin" = "3" - register "vsync" = "5" - register "left_margin" = "80" - register "right_margin" = "48" - register "hsync" = "32" - register "lcdbase" = "0x10000000" end -end + end

1 0

Patch merged into coreboot/master: 21efd8c haswell: fix ACPI MCFG table
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 21efd8c0378a8a42ee2fd71957be318416b6f5af Author: Aaron Durbin <adurbin(a)chromium.org> Date: Thu Jan 17 09:39:39 2013 -0600 haswell: fix ACPI MCFG table The acpi_fill_mcfg() was still using ivy/sandy PCI device ids which Hawell obviously doesn't have. This resulted in an empty MCFG table. Instead of relying on PCI device ids use dev/fn 0/0 since that is where the host bridge always resides. Additionally remove the defines for the IB and SB pci device ids. Replace them with mobile and ult Haswel device ids and use those in the pci driver tables for the northbridge code. Booted to Linux and noted that MCFG was properly parsed. Change-Id: Ieaab2dfef0e9daf3edbd8a27efe0825d2beb9443 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2748 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 23:35:31 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Mon Mar 18 17:11:24 2013, giving +2 See http://review.coreboot.org/2748 for details. -gerrit

1 0

Patch merged into coreboot/master: 7af2069 haswell: enable caching before SMM initialization
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 7af20698f69bbf10c4f18aa4fcc35ae7cf8cb866 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Mon Jan 14 14:54:41 2013 -0600 haswell: enable caching before SMM initialization The SMM handler resides in the TSEG region which is far above CONFIG_RAM_TOP (which is the highest cacheable address) before MTRRs are setup. This means that calling initialize_cpus() before performing MTRR setup on the BSP means the SMM handler is copied using uncacheable accesses. Improve the SMM handler setup path by enabling performing MTRR setup on for the BSP before the call to initialize_cpus(). In order to do this the haswell_init() function was split into 2 paths: BSP & AP paths. There is a cpu_common_init() that both call to perform similar functionality. The BSP path in haswell_init() then starts the APs using intel_cores_init(). The AP path in haswell_init() loads microcode and sets up MTRRs. This split will be leveraged for future support of bringing up APs in parallel as well as adhering to the Haswell MP initialization requirements. Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2746 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 23:13:28 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Mon Mar 18 17:10:17 2013, giving +2 See http://review.coreboot.org/2746 for details. -gerrit

1 0

Patch merged into coreboot/master: 24614af haswell: Clear correct number of MCA banks
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 24614af9b85bc615b0d9af3f37fa393de039c9f8 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Sat Jan 12 01:07:28 2013 -0600 haswell: Clear correct number of MCA banks The configure_mca() function was hard coding the number of banks the cpu supported. Query this dynamically so that it no longer clears only 7 banks. Change-Id: I33fce8fadc0facd1016b3295faaf3ae90e490a71 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2745 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 23:02:58 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Mon Mar 18 17:08:58 2013, giving +2 See http://review.coreboot.org/2745 for details. -gerrit

1 0

Patch merged into coreboot/master: a416bfe haswell: move definition of CORE_THREAD_COUNT_MSR
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit a416bfecedb7d55cf3c631d230e3500b314fc880 Author: Aaron Durbin <adurbin(a)chromium.org> Date: Sat Jan 12 00:45:10 2013 -0600 haswell: move definition of CORE_THREAD_COUNT_MSR This just moves the definiton of CORE_THREAD_COUNT_MSR so that future code can utilize it. Change-Id: I15a381090f21ff758288f55dc964b6694feb6064 Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2744 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 22:53:14 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Mon Mar 18 17:08:17 2013, giving +2 See http://review.coreboot.org/2744 for details. -gerrit

1 0

Patch merged into coreboot/master: 29ffa54 haswell: Use SMM Modules
by gerrit＠coreboot.org 18 Mar '13

18 Mar '13

the following patch was just integrated into master: commit 29ffa54969414b833de5c61b507b061f920d650b Author: Aaron Durbin <adurbin(a)chromium.org> Date: Fri Dec 21 21:21:48 2012 -0600 haswell: Use SMM Modules This commit adds support for using the SMM modules for haswell-based boards. The SMI handling was also refactored to put the relocation handler and permanent SMM handler loading in the cpu directory. All tseg adjustment support is dropped by relying on the SMM module support to perform the necessary relocations. Change-Id: I8dd23610772fc4408567d9f4adf339596eac7b1f Signed-off-by: Aaron Durbin <adurbin(a)chromium.org> Reviewed-on: http://review.coreboot.org/2728 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Mar 15 21:16:48 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Mon Mar 18 17:07:49 2013, giving +2 See http://review.coreboot.org/2728 for details. -gerrit

1 0

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