coreboot January 2013

coreboot@coreboot.org

32 participants
607 discussions

Patch set updated for coreboot: 71dcd75 cleanup some exynos5250 uart code
by David Hendricks 02 Jan '13

02 Jan '13

David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2084 -gerrit commit 71dcd75fa9b7dee8efc4a07b4d8e8c1b62acf807 Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:56:22 2012 -0800 cleanup some exynos5250 uart code This just cleans out some unused headers and tidies up the early serial code. TODO: Clean-up or replace FDT code, make "base_port" easier to configure. Change-Id: Ie77ee6d4935346e0053c09252055662f1a45d5f5 Signed-off-by: David Hendricks <dhendrix(a)chromium.org> --- src/cpu/samsung/exynos5250/uart.c | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/src/cpu/samsung/exynos5250/uart.c b/src/cpu/samsung/exynos5250/uart.c index 3d43976..9f4f7f3 100644 --- a/src/cpu/samsung/exynos5250/uart.c +++ b/src/cpu/samsung/exynos5250/uart.c @@ -21,14 +21,8 @@ * */ -//#include <common.h> -//#include <linux/compiler.h> #include <uart.h> #include <arch/io.h> -//#include <asm/arch-exynos/spl.h> -//#include <asm/global_data.h> -//#include <fdtdec.h> -//#include <serial.h> #include <console/console.h> /* for __console definition */ @@ -180,8 +174,6 @@ static unsigned char exynos5_uart_rx_byte(void) /* * Output a single byte to the serial port. */ -/* FIXME: ordering of arguments for coreboot v. u-boot for tx_byte */ -//static void exynos5_tx_byte(const char c, const int dev_index) static void exynos5_uart_tx_byte(unsigned char data) { // struct s5p_uart *const uart = s5p_get_base_uart(dev_index); @@ -198,14 +190,6 @@ static void exynos5_uart_tx_byte(unsigned char data) #ifndef __PRE_RAM__ static const struct console_driver exynos5_uart_console __console = { -//static const struct console_driver exynos5_uart_console __console = { -#if 0 - void (*init)(void); - void (*tx_byte)(unsigned char byte); - void (*tx_flush)(void); - unsigned char (*rx_byte)(void); - int (*tst_byte)(void); -#endif .init = exynos5_init_dev, .tx_byte = exynos5_uart_tx_byte, // .tx_flush = exynos5_uart_tx_flush, @@ -213,11 +197,6 @@ static const struct console_driver exynos5_uart_console __console = { // .tst_byte = exynos5_uart_tst_byte, }; #else -/* for romstage_console... */ -//void (*uart_init)(void) = exynos5_init_dev; -//unsigned char (*uart_rx_byte)(unsigned base_port) = exynos5_uart_rx_byte; -//void (*uart_tx_byte)(unsigned base_port, unsigned char data) = exynos5_uart_tx_byte; -/* FIXME: trivial wrappers */ void uart_init() { exynos5_init_dev();

1 0

Patch set updated for coreboot: 23c0bdd make early serial console support more generic
by David Hendricks 02 Jan '13

02 Jan '13

David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2086 -gerrit commit 23c0bdd5bc9118401f510b2bee8fa38b6e4b6a46 Author: David Hendricks <dhendrix(a)chromium.org> Date: Mon Dec 31 17:28:43 2012 -0800 make early serial console support more generic This patch makes pre-RAM serial init more generic, particularly for platforms which do not necessarily need cache-as-RAM in order to use the serial console and do not have a standard 8250 serial port. This adds a Kconfig variable to set romstage-* for very early serial console init. The current method assumes that cache-as-RAM should enable this, so to maintain compatibility selecting CACHE_AS_RAM will also select EARLY_SERIAL_CONSOLE. Change-Id: I089e7af633c227baf3c06c685f005e9d0e4b38ce Signed-off-by: David Hendricks <dhendrix(a)chromium.org> --- src/console/Kconfig | 7 +++++++ src/console/Makefile.inc | 2 +- src/console/console.c | 4 +++- src/cpu/Kconfig | 1 + src/include/uart.h | 4 ---- 5 files changed, 12 insertions(+), 6 deletions(-) diff --git a/src/console/Kconfig b/src/console/Kconfig index 117fdb8..a726c1f 100644 --- a/src/console/Kconfig +++ b/src/console/Kconfig @@ -5,6 +5,13 @@ config SERIAL_CONSOLE help Send coreboot debug output to a serial port +config EARLY_SERIAL_CONSOLE + bool + select SERIAL_CONSOLE + default n + help + Use serial console during early boot stages (e.g. cache-as-RAM) + config CONSOLE_SERIAL8250 bool "Serial port console output (I/O mapped, 8250-compatible)" depends on SERIAL_CONSOLE diff --git a/src/console/Makefile.inc b/src/console/Makefile.inc index a712486..3c4777f 100644 --- a/src/console/Makefile.inc +++ b/src/console/Makefile.inc @@ -10,7 +10,7 @@ smm-y += vtxprintf.c smm-$(CONFIG_SMM_TSEG) += die.c romstage-y += vtxprintf.c -romstage-$(CONFIG_CACHE_AS_RAM) += console.c +romstage-$(CONFIG_EARLY_SERIAL_CONSOLE) += console.c romstage-y += post.c romstage-y += die.c diff --git a/src/console/console.c b/src/console/console.c index d5f25a5..e92dbf6 100644 --- a/src/console/console.c +++ b/src/console/console.c @@ -99,13 +99,15 @@ int console_tst_byte(void) #else // __PRE_RAM__ ^^^ NOT defined vvv defined +#include <uart.h> + void console_init(void) { #if CONFIG_USBDEBUG enable_usbdebug(CONFIG_USBDEBUG_DEFAULT_PORT); early_usbdebug_init(); #endif -#if CONFIG_CONSOLE_SERIAL8250 +#if CONFIG_SERIAL_CONSOLE && !CONFIG_CONSOLE_SERIAL8250MEM uart_init(); #endif #if CONFIG_DRIVERS_OXFORD_OXPCIE && CONFIG_CONSOLE_SERIAL8250MEM diff --git a/src/cpu/Kconfig b/src/cpu/Kconfig index 383ba79..ddc46cf 100644 --- a/src/cpu/Kconfig +++ b/src/cpu/Kconfig @@ -16,6 +16,7 @@ source src/cpu/x86/Kconfig config CACHE_AS_RAM bool + select EARLY_SERIAL_CONSOLE default !ROMCC config DCACHE_RAM_BASE diff --git a/src/include/uart.h b/src/include/uart.h index 931d6dc..ea371c4 100644 --- a/src/include/uart.h +++ b/src/include/uart.h @@ -15,10 +15,6 @@ * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - * - * FIXME(dhendrix): This file contains generic prototypes for UART functions. - * The existing headers are too specific to the 8250, so we need a better - * abstraction for use with non-8250 UARTs. */ #ifndef UART_H

1 0

Patch set updated for coreboot: fea3790 import SPL files for board_i2c_{claim, release}_bus()
by David Hendricks 02 Jan '13

02 Jan '13

David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2081 -gerrit commit fea3790fda51a57c2e7c047232f445ce6c9d8c82 Author: David Hendricks <dhendrix(a)chromium.org> Date: Thu Dec 27 15:11:27 2012 -0800 import SPL files for board_i2c_{claim,release}_bus() This imports SPL (second phase loader) files from U-Boot. Most of the content of these files will eventually go away since they're fairly U-Boot specific. For now they are here to make Jenkins happy. Change-Id: Ib3a365ecb9dc304b20f7c1c06665aad2c0c53e69 Signed-off-by: David Hendricks <dhendrix(a)chromium.org> --- src/cpu/samsung/exynos5-common/spl.h | 4 ++++ src/mainboard/google/snow/smdk5250_spl.c | 30 ++++++++++++++++++++++++++++-- 2 files changed, 32 insertions(+), 2 deletions(-) diff --git a/src/cpu/samsung/exynos5-common/spl.h b/src/cpu/samsung/exynos5-common/spl.h index afa9a8e..439e1b0 100644 --- a/src/cpu/samsung/exynos5-common/spl.h +++ b/src/cpu/samsung/exynos5-common/spl.h @@ -91,4 +91,8 @@ struct spl_machine_param *spl_get_machine_params(void); */ void spl_early_init(void); +/* FIXME(dhendrix): for early i2c init */ +void board_i2c_release_bus(int node); +int board_i2c_claim_bus(int node); + #endif /* __ASM_ARCH_EXYNOS_SPL_H__ */ diff --git a/src/mainboard/google/snow/smdk5250_spl.c b/src/mainboard/google/snow/smdk5250_spl.c index 204e411..0dbd4e1 100644 --- a/src/mainboard/google/snow/smdk5250_spl.c +++ b/src/mainboard/google/snow/smdk5250_spl.c @@ -24,8 +24,7 @@ #define SIGNATURE 0xdeadbeef /* Parameters of early board initialization in SPL */ -static struct spl_machine_param machine_param - __attribute__((section(".machine_param"))) = { +static struct spl_machine_param machine_param = { .signature = SIGNATURE, .version = 1, .params = "vmubfasirMw", @@ -65,6 +64,18 @@ struct spl_machine_param *spl_get_machine_params(void) return &machine_param; } +#if 0 +int board_get_revision(void) +{ + struct spl_machine_param *params = spl_get_machine_params(); + unsigned gpio[CONFIG_BOARD_REV_GPIO_COUNT]; + + gpio[0] = params->board_rev_gpios & 0xffff; + gpio[1] = params->board_rev_gpios >> 16; + return gpio_decode_number(gpio, CONFIG_BOARD_REV_GPIO_COUNT); +} +#endif + int board_wakeup_permitted(void) { struct spl_machine_param *param = spl_get_machine_params(); @@ -76,3 +87,18 @@ int board_wakeup_permitted(void) return !is_bad_wake; } + +/* + * TODO(sjg(a)chromium.org): + * Declared there here for SPL, since there is no core i2c subsystem and + * cmd_i2c.c is not included. + */ +void board_i2c_release_bus(int node) +{ +} + +int board_i2c_claim_bus(int node) +{ + /* EC is not allowed to touch the bus until we enter U-Boot */ + return 0; +}

1 0

Patch set updated for coreboot: 1c27787 armv7: create init.S for early ARMv7 init
by David Hendricks 02 Jan '13

02 Jan '13

David Hendricks (dhendrix(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2083 -gerrit commit 1c27787a247123f6f966d7774c117c0899c089aa Author: David Hendricks <dhendrix(a)chromium.org> Date: Thu Dec 27 15:23:57 2012 -0800 armv7: create init.S for early ARMv7 init The old start.S file did a lot of work and had AP-specific #ifndef's. The new init.S will eventually contain only bare minimum generic ARM code for use by the bootblock. Processor-specific stuff and things that take place later in the boot process should go elsewhere. Change-Id: I7db0a77ee4bbad1ddecb193ea125d8941a50532b Signed-off-by: David Hendricks <dhendrix(a)chromium.org> --- src/arch/armv7/Makefile.inc | 4 +- src/arch/armv7/init/init.S | 94 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 95 insertions(+), 3 deletions(-) diff --git a/src/arch/armv7/Makefile.inc b/src/arch/armv7/Makefile.inc index b413d3e..1a1271f 100644 --- a/src/arch/armv7/Makefile.inc +++ b/src/arch/armv7/Makefile.inc @@ -142,9 +142,7 @@ endif CFLAGS += -D__KERNEL__ CFLAGS += -D__LINUX_ARM_ARCH__=7 -# FIXME(dhendrix): trying to split start.S apart... -crt0s = $(src)/arch/armv7/start.S -#crt0s = $(src)/arch/armv7/romstage.S +crt0s = $(src)/arch/armv7/init/init.S ldscripts = ldscripts += $(src)/arch/armv7/romstage.ld diff --git a/src/arch/armv7/init/init.S b/src/arch/armv7/init/init.S new file mode 100644 index 0000000..033637e --- /dev/null +++ b/src/arch/armv7/init/init.S @@ -0,0 +1,94 @@ +/* + * Early initialization code for ARMv7 architecture. + * + * This file is based off of the OMAP3530/ARM Cortex start.S file from Das + * U-Boot, which itself got the file from armboot. + * + * Copyright (c) 2004 Texas Instruments <r-woodruff2(a)ti.com> + * Copyright (c) 2001 Marius Gröger <mag(a)sysgo.de> + * Copyright (c) 2002 Alex Züpke <azu(a)sysgo.de> + * Copyright (c) 2002 Gary Jennejohn <garyj(a)denx.de> + * Copyright (c) 2003 Richard Woodruff <r-woodruff2(a)ti.com> + * Copyright (c) 2003 Kshitij <kshitij(a)ti.com> + * Copyright (c) 2006-2008 Syed Mohammed Khasim <x0khasim(a)ti.com> + * Copyright (c) 2013 The Chromium OS Authors + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#define __ASSEMBLY__ +#include <system.h> + +.globl _start +_start: b reset + ldr pc, _undefined_instruction + ldr pc, _software_interrupt + ldr pc, _prefetch_abort + ldr pc, _data_abort + ldr pc, _not_used + ldr pc, _irq + ldr pc, _fiq +_undefined_instruction: .word _undefined_instruction +_software_interrupt: .word _software_interrupt +_prefetch_abort: .word _prefetch_abort +_data_abort: .word _data_abort +_not_used: .word _not_used +_irq: .word _irq +_fiq: .word _fiq +_pad: .word 0x12345678 /* now 16*4=64 */ + + .balignl 16,0xdeadbeef + +reset: + /* + * set the cpu to SVC32 mode + */ + mrs r0, cpsr + bic r0, r0, #0x1f + orr r0, r0, #0xd3 + msr cpsr,r0 + + /* + * From Cortex-A Series Programmer's Guide: + * Only CPU 0 performs initialization. Other CPUs go into WFI + * to do this, first work out which CPU this is + * this code typically is run before any other initialization step + */ + mrc p15, 0, r1, c0, c0, 5 @ Read Multiprocessor Affinity Register + and r1, r1, #0x3 @ Extract CPU ID bits + cmp r1, #0 + bne wait_for_interrupt @ If this is not core0, wait + + /* Set V=0 in CP15 SCTRL register - for VBAR to point to vector */ + mrc p15, 0, r0, c1, c0, 0 @ Read CP15 SCTRL Register + bic r0, #CR_V @ V = 0 + mcr p15, 0, r0, c1, c0, 0 @ Write CP15 SCTRL Register + + /* Set vector address in CP15 VBAR register */ + ldr r0, =_start + mcr p15, 0, r0, c12, c0, 0 @Set VBAR + +/* Set stackpointer in internal RAM to call board_init_f */ +call_board_init_f: + ldr sp, =(CONFIG_SYS_INIT_SP_ADDR) + mov sp, r0 + bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ + ldr r0,=0x00000000 + bl board_init_f + +wait_for_interrupt: + wfi + mov pc, lr @ back to my caller

1 0

Patch merged into coreboot/master: f50fbe8 AGESA: Use `Flag=AGESA_SUCCESS` instead of `TRUE` in DMI related functions
by gerrit＠coreboot.org 02 Jan '13

02 Jan '13

the following patch was just integrated into master: commit f50fbe82ad0837ae7b30d7e2a5570ffc0dcc3950 Author: Aladyshev Konstantin <aladyshev(a)nicevt.ru> Date: Wed Dec 19 09:31:01 2012 +0400 AGESA: Use `Flag=AGESA_SUCCESS` instead of `TRUE` in DMI related functions Success return value in DMI functions GetDmiInfoMain(..) and GetType4Type7Info(...) of AGESA vendorcode is "Flag = TRUE". This results in a failure of init late function: "agesawrapper_amdinitlate failed: 1" It happens because TRUE = 1 = AGESA_UNSUPPORTED. Replacing TRUE with AGESA_SUCCESS (= 0) fixes this problem. Only family f15tn does not have such bug. This patch just replaces TRUE with AGESA_SUCCESS, but maybe all DMI functions should be copied from Trinity family? Tested on Supermicro H8QGI board with 4 AMD Opteron 6234 processors (f15). Change-Id: I51bf91333c088a825b92d4a44d1ebe4380c8026c Signed-off-by: Aladyshev Konstantin <aladyshev(a)nicevt.ru> Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2070 Reviewed-by: Marc Jones <marcj303(a)gmail.com> Tested-by: build bot (Jenkins) Build-Tested: build bot (Jenkins) at Wed Jan 2 20:35:22 2013, giving +1 Reviewed-By: Marc Jones <marcj303(a)gmail.com> at Wed Jan 2 20:26:02 2013, giving +2 See http://review.coreboot.org/2070 for details. -gerrit

1 0

Re: [coreboot] Feedback On Coreboot: the Solution to the Secure Boot Fiasco
by David Hubbard 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 11:04 AM, ron minnich <rminnich(a)gmail.com> wrote: > On Wed, Jan 2, 2013 at 9:58 AM, Andrew Goodbody <ajg4tadpole(a)gmail.com> > wrote: > > > I am sure that it is the old story, most testing will be done against > > Windows. Anything more will be the exception. This is where the pressure > > needs to be put on the platform vendors as this is the part that they are > > responsible for. > > Sorry, vendors don't have a pattern of paying attention to end user > sales issues such as "won't boot Linux". They are selling into a > market in which Linux is about 1% at best of sales. That's been the > common experience anyway, even at very large companies: BIOS issues > just don't get fixed. > > Andrew, Ron, what's your take on http://mjg59.dreamwidth.org/20916.html ? Specifically: "This is part of Windows 8's fast boot support - the keyboard may not be initialised until after the OS has started." So the logic goes: 1. Secure Boot enabled and Win8 installed by the OEM 2. To access the BIOS, press F2/F8/DEL/whatever 3. "Fast boot" (hey! coreboot delivered on that first!) skips keyboard init 4. User is thus *forced* to use Win8's "hold down shift and restart" feature -- adding another barrier before a user can boot her own OS. I think the biggest problem here is that the entire BIOS is made inaccessible, and only if Windows gives permission can you change that. Regards, David

1 0

BIOS vendors and Linux testing (was: Feedback On Coreboot: the Solution to the Secure Boot Fiasco)
by Paul Menzel 02 Jan '13

02 Jan '13

Am Mittwoch, den 02.01.2013, 10:04 -0800 schrieb ron minnich: > On Wed, Jan 2, 2013 at 9:58 AM, Andrew Goodbody <ajg4tadpole(a)gmail.com> wrote: > > > I am sure that it is the old story, most testing will be done against > > Windows. Anything more will be the exception. This is where the pressure > > needs to be put on the platform vendors as this is the part that they are > > responsible for. > > Sorry, vendors don't have a pattern of paying attention to end user > sales issues such as "won't boot Linux". They are selling into a > market in which Linux is about 1% at best of sales. That's been the > common experience anyway, even at very large companies: BIOS issues > just don't get fixed. Well at least ASRock did test Ubuntu on one system and fixed it. This is in the changelog for BIOS version 1.70 for the ASRock E350M1 [1]. »2. Modify Ubuntu 12.04 can not shutdown issue.« I guess either the coreboot porters told them, Canonical exercised pressure or one of the ASRock employees uses Ubuntu at home. ;-) Thanks, Paul [1] http://www.asrock.com/mb/overview.asp?cat=Download&os=BIOS&Model=E350M1

1 0

Patch set updated for coreboot: e0d9046 AGESA: Use `Flag=AGESA_SUCCESS` instead of `TRUE` in DMI related functions
by Marc Jones 02 Jan '13

02 Jan '13

Marc Jones (marcj303(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2070 -gerrit commit e0d9046b9f22271480bd267dc01d4310664d2f79 Author: Aladyshev Konstantin <aladyshev(a)nicevt.ru> Date: Wed Dec 19 09:31:01 2012 +0400 AGESA: Use `Flag=AGESA_SUCCESS` instead of `TRUE` in DMI related functions Success return value in DMI functions GetDmiInfoMain(..) and GetType4Type7Info(...) of AGESA vendorcode is "Flag = TRUE". This results in a failure of init late function: "agesawrapper_amdinitlate failed: 1" It happens because TRUE = 1 = AGESA_UNSUPPORTED. Replacing TRUE with AGESA_SUCCESS (= 0) fixes this problem. Only family f15tn does not have such bug. This patch just replaces TRUE with AGESA_SUCCESS, but maybe all DMI functions should be copied from Trinity family? Tested on Supermicro H8QGI board with 4 AMD Opteron 6234 processors (f15). Change-Id: I51bf91333c088a825b92d4a44d1ebe4380c8026c Signed-off-by: Aladyshev Konstantin <aladyshev(a)nicevt.ru> Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> --- src/vendorcode/amd/agesa/f10/Proc/CPU/Feature/cpuDmi.c | 4 ++-- src/vendorcode/amd/agesa/f12/Proc/CPU/Feature/cpuDmi.c | 4 ++-- src/vendorcode/amd/agesa/f14/Proc/CPU/Feature/cpuDmi.c | 4 ++-- src/vendorcode/amd/agesa/f15/Proc/CPU/Feature/cpuDmi.c | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/vendorcode/amd/agesa/f10/Proc/CPU/Feature/cpuDmi.c b/src/vendorcode/amd/agesa/f10/Proc/CPU/Feature/cpuDmi.c index 9e7ea86..2496779 100644 --- a/src/vendorcode/amd/agesa/f10/Proc/CPU/Feature/cpuDmi.c +++ b/src/vendorcode/amd/agesa/f10/Proc/CPU/Feature/cpuDmi.c @@ -206,7 +206,7 @@ GetDmiInfoMain ( LOCATE_HEAP_PTR LocateHeapParams; MsrData = 0; - Flag = TRUE; + Flag = AGESA_SUCCESS; DmiBufferPtr = *DmiTable; if (DmiBufferPtr == NULL) { // @@ -387,7 +387,7 @@ GetType4Type7Info ( PROC_FAMILY_TABLE *ProcData; CPU_LOGICAL_ID LogicalID; - Flag = TRUE; + Flag = AGESA_SUCCESS; DmiBufferPtr = (DMI_INFO *) ApExeParams->RelatedDataBlock; GetLogicalIdOfCurrentCore (&LogicalID, &ApExeParams->StdHeader); diff --git a/src/vendorcode/amd/agesa/f12/Proc/CPU/Feature/cpuDmi.c b/src/vendorcode/amd/agesa/f12/Proc/CPU/Feature/cpuDmi.c index 60095d0..999ccf5 100644 --- a/src/vendorcode/amd/agesa/f12/Proc/CPU/Feature/cpuDmi.c +++ b/src/vendorcode/amd/agesa/f12/Proc/CPU/Feature/cpuDmi.c @@ -216,7 +216,7 @@ GetDmiInfoMain ( CPU_GET_MEM_INFO CpuGetMemInfo; MsrData = 0; - Flag = TRUE; + Flag = AGESA_SUCCESS; ProcData = NULL; MemInfo = NULL; DmiBufferPtr = *DmiTable; @@ -415,7 +415,7 @@ GetType4Type7Info ( PROC_FAMILY_TABLE *ProcData; CPU_LOGICAL_ID LogicalID; - Flag = TRUE; + Flag = AGESA_SUCCESS; DmiBufferPtr = (DMI_INFO *) ApExeParams->RelatedDataBlock; GetLogicalIdOfCurrentCore (&LogicalID, &ApExeParams->StdHeader); diff --git a/src/vendorcode/amd/agesa/f14/Proc/CPU/Feature/cpuDmi.c b/src/vendorcode/amd/agesa/f14/Proc/CPU/Feature/cpuDmi.c index 0bf357d..b816732 100644 --- a/src/vendorcode/amd/agesa/f14/Proc/CPU/Feature/cpuDmi.c +++ b/src/vendorcode/amd/agesa/f14/Proc/CPU/Feature/cpuDmi.c @@ -220,7 +220,7 @@ GetDmiInfoMain ( CPU_GET_MEM_INFO CpuGetMemInfo; MsrData = 0; - Flag = TRUE; + Flag = AGESA_SUCCESS; ProcData = NULL; MemInfo = NULL; DmiBufferPtr = *DmiTable; @@ -429,7 +429,7 @@ GetType4Type7Info ( PROC_FAMILY_TABLE *ProcData; CPU_LOGICAL_ID LogicalID; - Flag = TRUE; + Flag = AGESA_SUCCESS; DmiBufferPtr = (DMI_INFO *) ApExeParams->RelatedDataBlock; GetLogicalIdOfCurrentCore (&LogicalID, &ApExeParams->StdHeader); diff --git a/src/vendorcode/amd/agesa/f15/Proc/CPU/Feature/cpuDmi.c b/src/vendorcode/amd/agesa/f15/Proc/CPU/Feature/cpuDmi.c index 5619df3..2385752 100644 --- a/src/vendorcode/amd/agesa/f15/Proc/CPU/Feature/cpuDmi.c +++ b/src/vendorcode/amd/agesa/f15/Proc/CPU/Feature/cpuDmi.c @@ -219,7 +219,7 @@ GetDmiInfoMain ( CPU_GET_MEM_INFO CpuGetMemInfo; MsrData = 0; - Flag = TRUE; + Flag = AGESA_SUCCESS; ProcData = NULL; MemInfo = NULL; DmiBufferPtr = *DmiTable; @@ -439,7 +439,7 @@ GetType4Type7Info ( CPU_LOGICAL_ID LogicalID; UINT8 L3Associativity; - Flag = TRUE; + Flag = AGESA_SUCCESS; DmiBufferPtr = (DMI_INFO *) ApExeParams->RelatedDataBlock; GetLogicalIdOfCurrentCore (&LogicalID, &ApExeParams->StdHeader);

1 0

Patch merged into coreboot/master: c855dce Supermicro H8QGI: Pass callout pointer to AmdReadEventLog function
by gerrit＠coreboot.org 02 Jan '13

02 Jan '13

the following patch was just integrated into master: commit c855dce8250b6c1820f682fb4a009d37e6d59826 Author: Aladyshev Konstantin <aladyshev(a)nicevt.ru> Date: Wed Dec 19 05:53:53 2012 +0400 Supermicro H8QGI: Pass callout pointer to AmdReadEventLog function I have issues when AmdReadEventLog function tries to use BiosCallouts interface. So it is necessary to provide callout pointer to this function. Change-Id: I4080e5f07d5d28c41688b2a7deff944b7a0f7bf7 Signed-off-by: Aladyshev Konstantin <aladyshev(a)nicevt.ru> Reviewed-on: http://review.coreboot.org/2064 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marcj303(a)gmail.com> Reviewed-by: Zheng Bao <zheng.bao(a)amd.com> Build-Tested: build bot (Jenkins) at Thu Dec 20 18:45:03 2012, giving +1 Reviewed-By: Marc Jones <marcj303(a)gmail.com> at Fri Dec 28 21:20:53 2012, giving +2 See http://review.coreboot.org/2064 for details. -gerrit

1 0

Re: [coreboot] Feedback On Coreboot: the Solution to the Secure Boot Fiasco
by Andrew Goodbody 02 Jan '13

02 Jan '13

On 02/01/13 17:08, ron minnich wrote: > On Mon, Dec 31, 2012 at 11:23 AM, David Hubbard > <david.c.hubbard+coreboot(a)gmail.com> wrote: > >> Andrew has good points. Technically there's nothing about Secure Boot that >> can be proven to exclude alternative OS's such as Linux. > > While that is technically true, I am starting to see reports of > systems that, at the very least, are making it hard to boot anything > but Windows. Also. Microsoft has exercised its power to limit the > types of binaries that will be signed, e.g. anything built with GPL V3 > will not be signed. Now, while they may have valid reasons, this does > demonstrate the extent of Microsoft's power over platforms with Secure > Boot. I find it worrisome. Hmm the GPL v3 thing is indeed troublesome. However shim is being signed which does at least give us one way to boot GNU/Linux without turning Secure Boot off. You can then of course use GPL v3 code in the bootpath after shim. > Given what a mess the vendors have made of $PIR/_MP/ACPI over the > years, I don't see the UEFI Secure Boot situation being much better. > So, get ready for desktops/laptops that "should" boot non-Windows > OSes, but don't. I am sure that it is the old story, most testing will be done against Windows. Anything more will be the exception. This is where the pressure needs to be put on the platform vendors as this is the part that they are responsible for. When you find motherboards that will only boot Windows then make a noise about it, complain and send them back. When you find motherboards that work correctly then also make a noise but do it complimenting the vendor. > Garret's blog is well worth reading on this whole issue. Yes. > ron > Andrew

2 1

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 January 2013