coreboot October 2009

coreboot@coreboot.org

63 participants
534 discussions

[v2] r4823 - trunk/coreboot-v2/src/cpu/amd/model_lx
by svn＠coreboot.org 22 Oct '09

22 Oct '09

Author: stepan Date: 2009-10-22 18:59:33 +0200 (Thu, 22 Oct 2009) New Revision: 4823 Modified: trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c Log: trivial: add note that VSA blob belongs into CBFS. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c =================================================================== --- trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c 2009-10-22 02:54:25 UTC (rev 4822) +++ trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c 2009-10-22 16:59:33 UTC (rev 4823) @@ -291,6 +291,7 @@ * much better parameterized */ + // TODO this is a CBFS candidate //VSA is cat onto the end after LB builds rom = ((unsigned long)0) - (CONFIG_ROM_SIZE + 36 * 1024); buf = (unsigned char *)VSA2_BUFFER;

1 0

Kontron doesn't build with Kconfig
by Myles Watson 22 Oct '09

22 Oct '09

SMM support hasn't been added yet. Should we disable SMI for Kontron, or does someone who understands it want to add the code to the Makefiles? It doesn't look that bad, but it will be a lot easier for someone who is already familiar with it. Thanks, Myles

1 0

support for hp eVectra p2706t (i810-based)
by Paweł Stawicki 22 Oct '09

22 Oct '09

Hi All, I'm very new to coreboot. I'm trying to boot my old hp eVectra with coreboot (because my old bios don't support VIA c3 processor) It took me some time to understand why my onboard VGA card don't starts, but now it works :-) Now I have a new problem. My linux distribution boots very slow (approximately 30 minutes - to the login prompt). I found this mail: [PATCH] Initial support for the MSI MS-6178 (i810-based)<http://news.gmane.org/find-root.php?message_id=%3c20070831091956.GA9039%40g…> From: Uwe Hermann with the same problem but I could not find the solution in the mailing thread. can someone help me ps. Sorry for my bad English

6 19

PCI config
by Myles Watson 22 Oct '09

22 Oct '09

The attached patch fixes booting for arima/hdama. How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? Thanks, Myles

3 9

booting fails on FAM10 machine
by Maximilian Thuermer 22 Oct '09

22 Oct '09

Hi all, I did a fresh svn co the other day and tried building and running a Tyan S2912_fam10 system. With older sources (rev 4729) everything worked just fine, with the newest checkout the booting process stops at setting MTRR registers or a little later (depending on the compiler used: 3.4.6 builds faster code and gets further than 4.3.3, both Ubuntu fashion). I tried tracking down the problem and it appeared to me as if the switch from CONFIG_LB_MEM_TOPK to CONFIG_RAMTOP must have something to do with this though I couldnt find an error when comparing all the files affected by this switch. Attached are the last lines of the debug printout. Does anyone have an idea, where this error might come from or if there are any unintended side effects associated with this change? Thanks in advance, Maximilian -- Maximilian Thuermer University of Heidelberg Zentrales Institut für Technische Informatik (ziti) Computer Architecture Group B 6, 26, 68131 Mannheim http://ra.ziti.uni-heidelberg.de email: maximilian.thuermer(a)ziti.uni-heidelberg.de Initializing devices... Root Device init APIC_CLUSTER: 0 init start_eip=0x0000d000, offset=0x00100000, code_size=0x0000005b Initializing CPU #0 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 00, coreid = 00 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0xffff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x00 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #0 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 1. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 1. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #1 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 00, coreid = 01 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0xffff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x01 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #1 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 2. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #2 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 00, coreid = 02 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0xffff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x02 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #2 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 3. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 3. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #3 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 00, coreid = 03 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0xffff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x03 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #3 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 4. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 4. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #4 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 01, coreid = 00 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 1, base: 8192MB, range: 512MB, type WB ADDRESS_MASK_HIGH=0xffff Setting variable MTRR 2, base: 3584MB, range: 512MB, type UC ADDRESS_MASK_HIGH=0xffff DONE variable MTRRs Clear out the extra MTRR's call enable_var_mtrr() Leave x86_setup_var_mtrrs MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0x04 done. CPU model: AMD Thermal Test Kit siblings = 03, CPU #4 initialized Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1 to 5. After apic_write. Startup point 1. Waiting for send to finish... +Sending STARTUP #2 to 5. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Initializing CPU #5 CPU: vendor AMD device 100f42 CPU: family 10, model 04, stepping 02 nodeid = 01, coreid = 01 Enabling cache Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-88) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-88) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-0) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(0-88) Type: WB, RdMEM, WrMEM CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.3 | VT102 | Offline

2 1

[PATCH] Make various DEBUG defines user-configurable in menuconfig
by Uwe Hermann 22 Oct '09

22 Oct '09

See patch. Note that we need code-fixes for some chipsets and board when enabling some of the DEBUG options (my guess is that code was never tested much), but this is not related to my patch, those problems have been there already: - Some romcc boards throw "too few registers" errors if you enable extra debugging options. That can partly fixed by changing code or by changing -mcpu=i386 to -mcpu=p2 or similar (if possible for the board/CPU). - Some chipset code needs fixing as boards won't even compile if some of the DEBUG options are enabled. - And there are further DEBUG* defines which are not so easily converted (e.g. some use integers like LOGLEVEL does, instead of just boolean on/off). I will have a look at converting more of those to kconfig later. Uwe. -- http://www.hermann-uwe.de | http://www.randomprojects.org http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

3 7

Help getting a P2B board running with coreboot
by Mark Marshall 22 Oct '09

22 Oct '09

Hi. I've been lurking here for some time, and am slowly trying to get a ASUS P2B board to run with coreboot. This is mainly so that I can get to grips with how coreboot works - the P2B seemed to be an easy starting point (well documented and cheap, they're on e-bay for < £10). I've built a ROM image from earlier today and loaded it into a flash, and I do get some serial output. I can see coreboot attempts to initialize the memory and then hangs when it tries to copy the CBFS image to RAM. I uncommented one of the lines in the auto.c file so that I do a memory test just before the copy from cbfs. The hang occurs when writing to the RAM. I looked at the assembler, and it was using the MOVNTI instruction, which I don't think is supported by the CPU I'm using. After changing the HAVE_MOVNTI build define I tried again, this time I get a reset when writing to the RAM. The RAM that I'm using isn't a 64MB one, and the raminit code implies that it may only work with this size of chip. Is this something easy that I can change (if this is the only problem then there's a good chance that I can work out the correct values from the data sheet)? Are there other reasons why a P2B board won't just run out of the box? What else can be causing a write to RAM to go wrong? What other tests can I make? Is there a know-good revision from SVN that I can sync to knowing that that version will(should) work? If I use serialice (or something else) what do we expect to happen if I write to (or read from RAM) before it has been initialized? What about if it has been wrongly initialized? (I surprised that it seems to cause a reboot.) I know that these are basic questions, but any help would be greatly appreciated. MM

2 1

[PATCH] Technexion TIM-5690
by Libra Li 22 Oct '09

22 Oct '09

Hi, This is little modification for TIM-5690. Thanks. Signed-off-by: Libra Li <libra.li(a)technexion.com> Index: src/mainboard/technexion/tim5690/mainboard.c =================================================================== --- src/mainboard/technexion/tim5690/mainboard.c (revision 4821) +++ src/mainboard/technexion/tim5690/mainboard.c (working copy) @@ -47,37 +47,6 @@ uint64_t uma_memory_base, uma_memory_size; - -/*************************************************** -* This board, the TIM-5690 has two Marvel 88e5056 PCI-E -* 10/100/1000 chips on board. -* Both of their pin PERSTn pins are connected to GPIO 5 of the -* SB600 southbridge. -****************************************************/ -static void enable_onboard_nic() -{ - - u8 byte; - device_t sm_dev; - - printk_info("enable_onboard_nic.\n"); - - sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - - byte = pci_read_config8(sm_dev, 0x9a); - byte |= ( 1 << 7); - pci_write_config8(sm_dev, 0x9a, byte); - - byte=pm_ioread(0x59); - byte &= ~( 1<< 5); - pm_iowrite(0x59,byte); - - byte = pci_read_config8(sm_dev, 0xA8); - - byte |= (1 << 1); //set bit 1 to high - pci_write_config8(sm_dev, 0xA8, byte); -} - /* set thermal config */ static void set_thermal_config() @@ -193,7 +162,6 @@ uma_memory_base = 0x38000000; /* 1GB system memory supposed */ #endif - enable_onboard_nic(); set_thermal_config(); } Index: targets/technexion/tim5690/Config.lb =================================================================== --- targets/technexion/tim5690/Config.lb (revision 4821) +++ targets/technexion/tim5690/Config.lb (working copy) @@ -8,9 +8,6 @@ #option CONFIG_ROM_SIZE = (1024*1024*2) #option CONFIG_ROM_SIZE = (1024*1024*4) -option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 - - romimage "normal" option CONFIG_USE_FALLBACK_IMAGE=0 option CONFIG_ROM_IMAGE_SIZE=0x20000

3 3

[v2] r4822 - in trunk/coreboot-v2: src/mainboard/technexion/tim5690 targets/technexion/tim5690
by svn＠coreboot.org 22 Oct '09

22 Oct '09

Author: hailfinger Date: 2009-10-22 04:54:25 +0200 (Thu, 22 Oct 2009) New Revision: 4822 Modified: trunk/coreboot-v2/src/mainboard/technexion/tim5690/mainboard.c trunk/coreboot-v2/targets/technexion/tim5690/Config.lb Log: The LAN chip-set on the Technexion TIM-5690 is enabled by hardware and does not need any handling in software. Signed-off-by: Libra Li <libra.li(a)technexion.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/src/mainboard/technexion/tim5690/mainboard.c =================================================================== --- trunk/coreboot-v2/src/mainboard/technexion/tim5690/mainboard.c 2009-10-21 00:35:42 UTC (rev 4821) +++ trunk/coreboot-v2/src/mainboard/technexion/tim5690/mainboard.c 2009-10-22 02:54:25 UTC (rev 4822) @@ -47,37 +47,6 @@ uint64_t uma_memory_base, uma_memory_size; - -/*************************************************** -* This board, the TIM-5690 has two Marvel 88e5056 PCI-E -* 10/100/1000 chips on board. -* Both of their pin PERSTn pins are connected to GPIO 5 of the -* SB600 southbridge. -****************************************************/ -static void enable_onboard_nic() -{ - - u8 byte; - device_t sm_dev; - - printk_info("enable_onboard_nic.\n"); - - sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0)); - - byte = pci_read_config8(sm_dev, 0x9a); - byte |= ( 1 << 7); - pci_write_config8(sm_dev, 0x9a, byte); - - byte=pm_ioread(0x59); - byte &= ~( 1<< 5); - pm_iowrite(0x59,byte); - - byte = pci_read_config8(sm_dev, 0xA8); - - byte |= (1 << 1); //set bit 1 to high - pci_write_config8(sm_dev, 0xA8, byte); -} - /* set thermal config */ static void set_thermal_config() @@ -193,7 +162,6 @@ uma_memory_base = 0x38000000; /* 1GB system memory supposed */ #endif - enable_onboard_nic(); set_thermal_config(); } Modified: trunk/coreboot-v2/targets/technexion/tim5690/Config.lb =================================================================== --- trunk/coreboot-v2/targets/technexion/tim5690/Config.lb 2009-10-21 00:35:42 UTC (rev 4821) +++ trunk/coreboot-v2/targets/technexion/tim5690/Config.lb 2009-10-22 02:54:25 UTC (rev 4822) @@ -8,9 +8,6 @@ #option CONFIG_ROM_SIZE = (1024*1024*2) #option CONFIG_ROM_SIZE = (1024*1024*4) -option CONFIG_COMPRESSED_PAYLOAD_LZMA=1 - - romimage "normal" option CONFIG_USE_FALLBACK_IMAGE=0 option CONFIG_ROM_IMAGE_SIZE=0x20000

1 0

[blubkin@vmware.com: RE: [Openipmi-developer] [Discuss] [PATCH] ipmi: use round_jiffies on timers to reduce timer overhead/wakeups]
by Peter Stuge 22 Oct '09

22 Oct '09

Interesting notes from LKML and openipmi. An estimate was that kipmid hogs 10W from a 70W server. //Peter ----- Forwarded message from Bela Lubkin <blubkin(a)vmware.com> ----- From: Bela Lubkin <blubkin(a)vmware.com> To: 'Corey Minyard' <minyard(a)acm.org>, Randy Dunlap <randy.dunlap(a)oracle.com> CC: "discuss(a)LessWatts.org" <discuss(a)LessWatts.org>, "Kok, Auke" <auke-jan.h.kok(a)intel.com>, Arjan van de Ven <arjan(a)linux.intel.com>, "openipmi-developer(a)lists.sourceforge.net" <openipmi-developer(a)lists.sourceforge.net>, lkml <linux-kernel(a)vger.kernel.org> Subject: RE: [Openipmi-developer] [Discuss] [PATCH] ipmi: use round_jiffies on timers to reduce timer overhead/wakeups Date: Wed, 21 Oct 2009 16:46:41 -0700 Corey Minyard & Randy Dunlap wrote: Randy>> From what I recall (probably 2 years ago), [older] ipmi hardware Randy>> does not generate event interrupts, so it has to be polled. Randy>> Randy>> Corey, can you elaborate on this? Corey> Certainly. Yes, some (probably most) IPMI hardware does not use Corey> interrupts, and unfortunately, it's not just older machines. Corey> The driver used to poll more slowly, but in many cases the Corey> performance was unacceptable. Corey> Corey> kipmid is only started if the hardware doesn't support Corey> interrupts, so only users with sub-standard hardware have to Corey> suffer with this problem. Regrettably, of the "big three" in the "PC Server" world, only HP's iLO2 BMC supports interrupts. Dell's DRAC4 & 5 don't, IBM's ASM, RSA, etc. don't. Also (at least out of a sample of one) SuperMicro also doesn't have an interrupt. They also have all settled on the KCS interface, which dribbles one character through per non-interrupt. So sad. Dell's DRAC3 had a BT BMC which transferred whole IPMI packets via DMA _and_ had an interrupt. HP's ancient SMIC equipment also had an interrupt (but that's also char-by-char, and their current KCS has an interrupt, so at least they haven't regressed). I've guessed that some chip vendor must have come out with a Really Cheep KCS implementation and drove every other implementation out of the market. :-( I've heard rumors that some current Sun hardware has BT. >Bela<-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ----- End forwarded message -----

1 0

← Newer
1
...
19
20
21
22
23
24
25
...
54
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 October 2009