coreboot February 2013

coreboot@coreboot.org

27 participants
790 discussions

Patch merged into coreboot/master: 77608b2 armv7/snow: Remove power_init from bootblock.
by gerrit＠coreboot.org 07 Feb '13

07 Feb '13

the following patch was just integrated into master: commit 77608b21d3d745a10bba08fe316995a05f2371e2 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Thu Feb 7 21:25:15 2013 +0800 armv7/snow: Remove power_init from bootblock. The power_init is not required on Exynos 5250 (snow) in bootblock stage. To get a cleaner and faster bootblock, we can remove it. Note, power_init internally calls max77686 and s3c24x0_i2c, so both files are also removed. Verified to boot on armv7/snow. Change-Id: I5b15dfe5ac7bf4650565fea0afefc94a228ece29 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> Reviewed-on: http://review.coreboot.org/2317 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Thu Feb 7 15:26:22 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Thu Feb 7 18:15:25 2013, giving +2 See http://review.coreboot.org/2317 for details. -gerrit

1 0

Coreboot on Packard Bell Easynote mv35-100
by karim hamza 07 Feb '13

07 Feb '13

Hello, First of all, thank you for this great project I stumbled into coreboot while I was searching for solution for my problem I have an old laptop (Packard Bell Easynote mv35-100) with this problem : The laptop have no internal HDD so i'm using a 16GB-Flash drive to work with it , I use Live systems like ubuntu live edition or windows live editions (winpe) but the problem is although laptop can boot from USB it boots in very painfully slow speed the laptop has usb 2.0 ports and the USB drive is usb 2.0 but i get a very slow speed booting from it I tried everything , most boot-loaders i heard of, altering settings in bios (although there is not much to change) and updated bios to last version (dated 2007 ) So my qestion is: Is Coreboot able to initialize USB drive and boot from from with USB 2.0 support ? 2) My laptop isn't in the supported devices in the Coreboot site, Does this mean i can't install Coreboot firmware to my bios chip? 3) If yes, Can you help me through that? Thank you

1 0

Patch merged into coreboot/master: 60485a3 armv7/snow: Remove redundant I2C initialization calls in bootblock.
by gerrit＠coreboot.org 07 Feb '13

07 Feb '13

the following patch was just integrated into master: commit 60485a3e915ad44783d564e07d5ed6e7b74b277b Author: Hung-Te Lin <hungte(a)chromium.org> Date: Thu Feb 7 21:15:42 2013 +0800 armv7/snow: Remove redundant I2C initialization calls in bootblock. The I2C initialization (on component MAX77688) is already done in power_init, so we should not need an explicit call inside bootblock. Verified to boot on armv7/snow. Change-Id: I68c248a8b5fee4ab838b2fb708649e112559cc41 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> Reviewed-on: http://review.coreboot.org/2316 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich(a)gmail.com> Build-Tested: build bot (Jenkins) at Thu Feb 7 15:19:55 2013, giving +1 Reviewed-By: Ronald G. Minnich <rminnich(a)gmail.com> at Thu Feb 7 18:14:49 2013, giving +2 See http://review.coreboot.org/2316 for details. -gerrit

1 0

Re: [coreboot] building a coreboot (and 100% free software) compatible box
by "Kristóf, Csillag" 07 Feb '13

07 Feb '13

Was not the point of downloadable firmware exactly to replace those? Thought you could be right... Kristof 2013-02-07 14:47 keltezéssel, Антон Кочков írta: > Not sure, but it is _downloadable_ firmware, while here can be flashed > or burned firmware too. > > Best regards, > Anton Kochkov. > > > On Thu, Feb 7, 2013 at 1:46 PM, "Kristóf, Csillag" > <csillag.kristof(a)gmail.com> wrote: >> At 2013-02-07 09:45, "Kristóf, Csillag" wrote: >>> >>>> I think this means you'll need a discrete graphics card, as you mention >>>> in 2.1 below. Bitcoin just got ASICs so if you're the type to risk a scammer >>>> on fleabay, you could score a great deal. >>> OK, but what graphics card? Both AMD and Nvidia require binary >>> firmwares... >> Fortunately, that's not true! >> Nouveau can now run without a firmware on some cards. >> >> See here: >> >> http://nouveau.freedesktop.org/wiki/InstallDRM#A3D-accel_Firmware >> >> That's some progress... >> >> >> Csillag >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot

1 0

New patch to review for coreboot: a01d72e YABEL: use system {in, out}[bwl] on x86
by Patrick Georgi 07 Feb '13

07 Feb '13

Patrick Georgi (patrick(a)georgi-clan.de) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2318 -gerrit commit a01d72ed0d25ccb6b84c181780614b9f2d047def Author: Patrick Georgi <patrick.georgi(a)secunet.com> Date: Thu Feb 7 15:53:54 2013 +0100 YABEL: use system {in,out}[bwl] on x86 The prototypes that were recently defined only work for the internal implementations. Change-Id: Ib34bb75a0b882533da550b9cd17cd777c2463e02 Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> --- src/device/oprom/include/io.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/device/oprom/include/io.h b/src/device/oprom/include/io.h index d9b2139..96dd572 100644 --- a/src/device/oprom/include/io.h +++ b/src/device/oprom/include/io.h @@ -1,3 +1,6 @@ +#if CONFIG_ARCH_X86 +#include <arch/io.h> +#else void outb(u8 val, u16 port); void outw(u16 val, u16 port); void outl(u32 val, u16 port); @@ -5,5 +8,4 @@ void outl(u32 val, u16 port); u8 inb(u16 port); u16 inw(u16 port); u32 inl(u16 port); - - +#endif

1 0

Patch set updated for coreboot: 8ab5ab0 exynos/snow: Configure UART peripheral during console initialization.
by Hung-Te Lin 07 Feb '13

07 Feb '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2315 -gerrit commit 8ab5ab00fe60042f9204c99cda39a81304a320e1 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Thu Feb 7 19:30:40 2013 +0800 exynos/snow: Configure UART peripheral during console initialization. For Exynos platforms, the UART component on pinmux must be first selected and configured. This should be done as part of UART console initialization. Note, that the current implementation hard-codes the device index as UART3, while the base port can be assigned to different device in Kconfig. This will be fixed later. Verified to work on armv7/snow. Change-Id: Ie63e76e2dac09fec1132573d1b0027fce55333a1 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- src/cpu/samsung/exynos5250/uart.c | 3 +++ src/mainboard/google/snow/bootblock.c | 1 - 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/cpu/samsung/exynos5250/uart.c b/src/cpu/samsung/exynos5250/uart.c index dacdc10..3e80017 100644 --- a/src/cpu/samsung/exynos5250/uart.c +++ b/src/cpu/samsung/exynos5250/uart.c @@ -121,6 +121,9 @@ static void exynos5_init_dev(void) // struct s5p_uart *const uart = s5p_get_base_uart(dev_index); struct s5p_uart *uart = (struct s5p_uart *)base_port; + // TODO initialize with correct peripheral id by base_port. + exynos_pinmux_config(PERIPH_ID_UART3, PINMUX_FLAG_NONE); + /* enable FIFOs */ writel(0x1, &uart->ufcon); writel(0, &uart->umcon); diff --git a/src/mainboard/google/snow/bootblock.c b/src/mainboard/google/snow/bootblock.c index be5a99f..0bee055 100644 --- a/src/mainboard/google/snow/bootblock.c +++ b/src/mainboard/google/snow/bootblock.c @@ -42,7 +42,6 @@ void bootblock_mainboard_init(void) mem = get_mem_timings(); arm_ratios = get_arm_clk_ratios(); system_clock_init(mem, arm_ratios); - exynos_pinmux_config(PERIPH_ID_UART3, PINMUX_FLAG_NONE); console_init(); printk(BIOS_INFO, "\n\n\n%s: UART initialized\n", __func__);

1 0

New patch to review for coreboot: 72e806b armv7/snow: Remove power_init from bootblock.
by Hung-Te Lin 07 Feb '13

07 Feb '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2317 -gerrit commit 72e806bb26ee8be37feec1bc7ef06549b52f4260 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Thu Feb 7 21:25:15 2013 +0800 armv7/snow: Remove power_init from bootblock. The power_init is not required on Exynos 5250 (snow) in bootblock stage. To get a cleaner and faster bootblock, we can remove it. Note, power_init internally calls max77686 and s3c24x0_i2c, so both files are also removed. Verified to boot on armv7/snow. Change-Id: I5b15dfe5ac7bf4650565fea0afefc94a228ece29 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- src/cpu/samsung/exynos5250/Makefile.inc | 1 - src/cpu/samsung/s5p-common/Makefile.inc | 1 - src/drivers/maxim/max77686/Makefile.inc | 1 - src/mainboard/google/snow/bootblock.c | 2 -- 4 files changed, 5 deletions(-) diff --git a/src/cpu/samsung/exynos5250/Makefile.inc b/src/cpu/samsung/exynos5250/Makefile.inc index e2033ff..1c6d716 100644 --- a/src/cpu/samsung/exynos5250/Makefile.inc +++ b/src/cpu/samsung/exynos5250/Makefile.inc @@ -9,7 +9,6 @@ bootblock-y += clock_init.c bootblock-y += clock.c bootblock-y += pinmux.c -bootblock-y += power.c bootblock-y += soc.c bootblock-y += uart.c diff --git a/src/cpu/samsung/s5p-common/Makefile.inc b/src/cpu/samsung/s5p-common/Makefile.inc index 621576d..0f4200c 100644 --- a/src/cpu/samsung/s5p-common/Makefile.inc +++ b/src/cpu/samsung/s5p-common/Makefile.inc @@ -1,5 +1,4 @@ bootblock-y += pwm.c -bootblock-y += s3c24x0_i2c.c bootblock-y += s5p_gpio.c bootblock-y += timer.c diff --git a/src/drivers/maxim/max77686/Makefile.inc b/src/drivers/maxim/max77686/Makefile.inc index 097b291..a5d7b90 100644 --- a/src/drivers/maxim/max77686/Makefile.inc +++ b/src/drivers/maxim/max77686/Makefile.inc @@ -17,6 +17,5 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -bootblock-$(CONFIG_DRIVER_MAXIM_MAX77686) += max77686.c romstage-$(CONFIG_DRIVER_MAXIM_MAX77686) += max77686.c ramstage-$(CONFIG_DRIVER_MAXIM_MAX77686) += max77686.c diff --git a/src/mainboard/google/snow/bootblock.c b/src/mainboard/google/snow/bootblock.c index 8390ae8..bcfe440 100644 --- a/src/mainboard/google/snow/bootblock.c +++ b/src/mainboard/google/snow/bootblock.c @@ -27,7 +27,6 @@ #include <cpu/samsung/exynos5250/dmc.h> #include <cpu/samsung/exynos5250/periph.h> #include <cpu/samsung/exynos5250/clock_init.h> -#include <src/cpu/samsung/exynos5250/power.h> #endif @@ -37,7 +36,6 @@ void bootblock_mainboard_init(void) struct mem_timings *mem; struct arm_clk_ratios *arm_ratios; - power_init(); mem = get_mem_timings(); arm_ratios = get_arm_clk_ratios(); system_clock_init(mem, arm_ratios);

1 0

New patch to review for coreboot: dc594aa armv7/snow: Remove redundant I2C initialization calls in bootblock.
by Hung-Te Lin 07 Feb '13

07 Feb '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2316 -gerrit commit dc594aa1647d85e8e5292a356faff2c3dcc6b4b7 Author: Hung-Te Lin <hungte(a)chromium.org> Date: Thu Feb 7 21:15:42 2013 +0800 armv7/snow: Remove redundant I2C initialization calls in bootblock. The I2C initialization (on component MAX77688) is already done in power_init, so we should not need an explicit call inside bootblock. Verified to boot on armv7/snow. Change-Id: I68c248a8b5fee4ab838b2fb708649e112559cc41 Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- src/mainboard/google/snow/bootblock.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/src/mainboard/google/snow/bootblock.c b/src/mainboard/google/snow/bootblock.c index 64b12c6..8390ae8 100644 --- a/src/mainboard/google/snow/bootblock.c +++ b/src/mainboard/google/snow/bootblock.c @@ -23,15 +23,12 @@ #include <cbfs.h> #include <uart.h> #include <console/console.h> -#include <device/i2c.h> #include <cpu/samsung/exynos5250/clk.h> #include <cpu/samsung/exynos5250/dmc.h> #include <cpu/samsung/exynos5250/periph.h> #include <cpu/samsung/exynos5250/clock_init.h> #include <src/cpu/samsung/exynos5250/power.h> -#include <drivers/maxim/max77686/max77686.h> -#define I2C0_BASE 0x12c60000 #endif void bootblock_mainboard_init(void); @@ -40,8 +37,6 @@ void bootblock_mainboard_init(void) struct mem_timings *mem; struct arm_clk_ratios *arm_ratios; - i2c_set_early_reg(I2C0_BASE); - i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE); power_init(); mem = get_mem_timings(); arm_ratios = get_arm_clk_ratios();

1 0

Patch set updated for coreboot: bdc0af0 armv7/snow: Move clock initialization from bootblock to romstage.
by Hung-Te Lin 07 Feb '13

07 Feb '13

Hung-Te Lin (hungte(a)chromium.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/2308 -gerrit commit bdc0af083104286a3601e045802155c760b7098e Author: Hung-Te Lin <hungte(a)chromium.org> Date: Thu Feb 7 21:38:41 2013 +0800 armv7/snow: Move clock initialization from bootblock to romstage. Exynos system clock can be initialized before RAM init, not necessary to be in the very beginning (boot block). This helps reducing bootblock dependency. Verified to boot on armv7/snow. Change-Id: Ic863e222871a157ba4279a673775b1e18c6eac0d Signed-off-by: Hung-Te Lin <hungte(a)chromium.org> --- src/mainboard/google/snow/Makefile.inc | 4 ---- src/mainboard/google/snow/bootblock.c | 11 +---------- src/mainboard/google/snow/romstage.c | 9 ++++++++- 3 files changed, 9 insertions(+), 15 deletions(-) diff --git a/src/mainboard/google/snow/Makefile.inc b/src/mainboard/google/snow/Makefile.inc index 04bf543..b56a1a4 100644 --- a/src/mainboard/google/snow/Makefile.inc +++ b/src/mainboard/google/snow/Makefile.inc @@ -17,10 +17,6 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## -# needed for system_clock_init() -bootblock-y += mainboard.c -bootblock-y += memory.c - romstage-y += mainboard.c romstage-y += memory.c romstage-y += romstage.c diff --git a/src/mainboard/google/snow/bootblock.c b/src/mainboard/google/snow/bootblock.c index bcfe440..18306cc 100644 --- a/src/mainboard/google/snow/bootblock.c +++ b/src/mainboard/google/snow/bootblock.c @@ -23,23 +23,14 @@ #include <cbfs.h> #include <uart.h> #include <console/console.h> -#include <cpu/samsung/exynos5250/clk.h> -#include <cpu/samsung/exynos5250/dmc.h> #include <cpu/samsung/exynos5250/periph.h> -#include <cpu/samsung/exynos5250/clock_init.h> +#include <cpu/samsung/exynos5250/pinmux.h> #endif void bootblock_mainboard_init(void); void bootblock_mainboard_init(void) { - struct mem_timings *mem; - struct arm_clk_ratios *arm_ratios; - - mem = get_mem_timings(); - arm_ratios = get_arm_clk_ratios(); - system_clock_init(mem, arm_ratios); - #if CONFIG_EARLY_SERIAL_CONSOLE exynos_pinmux_config(PERIPH_ID_UART3, PINMUX_FLAG_NONE); uart_init(); diff --git a/src/mainboard/google/snow/romstage.c b/src/mainboard/google/snow/romstage.c index b8e5116..c0bb6f4 100644 --- a/src/mainboard/google/snow/romstage.c +++ b/src/mainboard/google/snow/romstage.c @@ -26,6 +26,7 @@ #include <cpu/samsung/exynos5250/dmc.h> #include <cpu/samsung/exynos5250/setup.h> +#include <cpu/samsung/exynos5250/clock_init.h> #include <console/console.h> #include <arch/stages.h> @@ -48,13 +49,19 @@ static int board_wakeup_permitted(void) void main(void) { struct mem_timings *mem; + struct arm_clk_ratios *arm_ratios; int ret; void *entry; + /* Clock must be initialized before console_init, otherwise you may need + * to re-initialize serial console drivers again. */ + mem = get_mem_timings(); + arm_ratios = get_arm_clk_ratios(); + system_clock_init(mem, arm_ratios); + console_init(); printk(BIOS_INFO, "hello from romstage\n"); - mem = get_mem_timings(); if (!mem) { printk(BIOS_CRIT, "Unable to auto-detect memory timings\n"); while(1);

1 0

Re: [coreboot] building a coreboot (and 100% free software) compatible box
by "Kristóf, Csillag" 07 Feb '13

07 Feb '13

Hi Hubbard, Thank you for your answer! At 2013-02-07 08:05, David Hubbard wrote: > Hi Csillag, > > [...] > I don't have experience with Intel motherboards. > > If this sounds like I'm pushing one specific motherboard, I apologize. > Rudolf Marek did a great job porting coreboot to the Asus F2A85-M board, Yeah, I am reading the thread. Congrats there. > and I bought one. I simply know the most about this board. > > The open source radeon driver performs just fine for this board (as > you mention below, yes, there is a binary blob). ... and as such, it does not fit the requirements (when used with on-board graphics.) > 1.2. It must have hardware support for AES. (For hw crypto > acceleration.) > > > For AMD that means you want a Bulldozer or Piledriver: > > http://en.wikipedia.org/wiki/AES_instruction_set#Supporting_CPUs_2 > http://en.wikipedia.org/wiki/Piledriver_%28processor%29#2012_platforms > > 1.4. It must have hardware support for virtualization. > > > Which specific virtualization features are you interested in? Everything that is available. What's AMD's equivalent of VT-d called nowadays? IOMMU or AMD-Vi ? > AMD CPUs should all have some virtualization capability. Coreboot + > virtualization has not been tested on the F2A85-M. Could you please test it? > > 1.5. It must be able to drive 3 independent display outputs, at > least in 1920x1200 resolution. > (Preferably all digital, but that's not necessary.) > > > The F2A85-M board has HDMI, DVI-D, and VGA sockets, but only works > with up to 2 displays. I can confirm that all three sockets work fine > with the open source radeon driver, and that dual-display works fine. That's fine, however, since the integrated GPU requires a binary firmware, it does not fit the requirements. > > ASUS does do 3-display motherboards, just not this one. Yep. There is a board with the same name & Pro prefix that is like that. (F2A85-M Pro.) However, that would sill require a binary firmware, so it would not fit the requirements, therefore, irrelevant. > I think this means you'll need a discrete graphics card, as you > mention in 2.1 below. Bitcoin just got ASICs so if you're the type to > risk a scammer on fleabay, you could score a great deal. OK, but what graphics card? Both AMD and Nvidia require binary firmwares... Is there something that does not? (And does 3 displays...) > > 1.6. I must _use_ this, in a production environment, therefore it > must work. Reliably. Now. I have ~15 yrs Linux programming > experience, have modified stuff inside the kernel and X drivers, > and I am not afraid to have my hands dirty, but now I am not here > to run a hobby project, I want to to buy something that works, so > that I can do my job using it. > > > Great! I understand that completely. The F2A85-M has some linux bugs: Thank you for the listing! > > 1.6.1. The motherboard realtek r8169 gigabit NIC will lock up the > system as it gets fully loaded (tested up to kernel 3.7.1). Consider > picking up a cheap PCI-E NIC and ignore the on-board NIC until the > bugs are well and truly fixed. OK, not a problem. > > 1.6.2. The hwmon sensors driver is still a work-in-progress with > significant bugs. The stock linux kernel doesn't do anything to hwmon, > which is fine for production use. Does not care. > > 1.6.3. I'll mention that there is almost no overclocking ability just > to be complete. The only thing coreboot supports is selecting the > proper voltage for DDR3 RAM at compile time. Does not care. > > 2. Would be nice: > > 2.1. It should only use integrated graphics. (Both Intel and AMD > can do 3 displays from integrated graphics now.) If I must, I > could add discrete card[s], but that increases power consumption > and system size... > > > Yep, integrated graphics can drive 1920x1200 but only 2 displays. (With binary firmware -> out of the question.) > > 2.2. Size small enough to be portable. Not planning to use in on > the move; I mean portable in a (potentially huge) backpack, > between several sites, where I intend to use them. > - size of Intel NUC or Thin Mini-ITX mainboard are very cool, > - Mini ITX is great, too, > - MicroATX is acceptable > - ATX seems to be too big, unless you can recommend me a > really, really small case (with acceptable cooling) > > > The F2A85-M is a MicroATX board, for what it's worth. That's fine. > > 2.3. Modern tech and High CPU performance. Of course :) Whatever > is available... > > > AMD really doesn't have anything that competes with high-end Intel CPUs. Indeed, this seems to be the case. > > 2.4. Low TDP, for the possibility of quite/silent cooling. > - definitely under 100W, > - probably at most 65W, > - ideally only 45W. > > > TDP for a high performance AMD CPU is ~100W. You mean something like the FX-8300, right? > I use an aftermarket heatsink and 120mm fan, and if you're willing to > get a high-end heatsink this board can be silent, even when the CPU > and GPU are running at 100%. I could do that, but that would about kill my chances to build this in a portable size. Oh well. > [...] > Now, if I understand correctly, the both GPU's (intel HD 4000 and > Radeon HD 7660D) runs on binary firmware blobs. > I have read about attempts to replace the Intel firmware with an > open version, but I am not sure where it stands now. > > What are my options here? > > > I didn't realize Intel HD 4000 uses a binary blob. That's interesting, > I'm going to go research that. I am not exactly sure how the binary part is used; it might be uploaded, or it might go into the BIOS. This is the part I was talking about: http://lists.freedesktop.org/archives/intel-gfx/2012-August/019353.html Thank you for your help: Csillag

2 2

← Newer
1
...
54
55
56
57
58
59
60
...
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 February 2013