coreboot May 2011

coreboot@coreboot.org

62 participants
161 discussions

[commit] r6576 - trunk/src/southbridge/amd/cimx_wrapper/sb800
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:18:59 2011 New Revision: 6576 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6576 Log: Configure CIMx to use 33 MHz fast mode for SPD read. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/SBPLATFORM.h Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/SBPLATFORM.h ============================================================================== --- trunk/src/southbridge/amd/cimx_wrapper/sb800/SBPLATFORM.h Sun May 15 23:13:00 2011 (r6575) +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/SBPLATFORM.h Sun May 15 23:18:59 2011 (r6576) @@ -116,8 +116,8 @@ #define cimHpetTimerDefault TRUE #define cimHpetMsiDisDefault FALSE // Enable #define cimIrConfigDefault 0x00 // Disable -#define cimSpiFastReadEnableDefault 0x00 // Disable -#define cimSpiFastReadSpeedDefault 0x00 // NULL +#define cimSpiFastReadEnableDefault 0x01 // Enable +#define cimSpiFastReadSpeedDefault 0x01 // 33 MHz // GPP/AB Controller #define cimNbSbGen2Default TRUE #define cimAlinkPhyPllPowerDownDefault TRUE

1 0

[commit] r6575 - trunk/src/mainboard/amd/persimmon
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:13:00 2011 New Revision: 6575 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6575 Log: Match DIMM SPD addressing to implemented slots. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/mainboard/amd/persimmon/dimmSpd.c Modified: trunk/src/mainboard/amd/persimmon/dimmSpd.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/dimmSpd.c Sun May 15 23:11:41 2011 (r6574) +++ trunk/src/mainboard/amd/persimmon/dimmSpd.c Sun May 15 23:13:00 2011 (r6575) @@ -35,7 +35,7 @@ // socket 0 { {0xA0, 0xA2}, // channel 0 dimms - {0xA4, 0xA8}, // channel 1 dimms + {0x00, 0x00}, // channel 1 dimms }, // socket 1 {

1 0

[commit] r6574 - trunk/src/mainboard/amd/persimmon
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:11:41 2011 New Revision: 6574 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6574 Log: Size mmconf according to CONFIG_MMCONF_BUS_NUMBER. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/mainboard/amd/persimmon/agesawrapper.c Modified: trunk/src/mainboard/amd/persimmon/agesawrapper.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/agesawrapper.c Sun May 15 23:10:20 2011 (r6573) +++ trunk/src/mainboard/amd/persimmon/agesawrapper.c Sun May 15 23:11:41 2011 (r6574) @@ -138,7 +138,8 @@ Set the MMIO Configuration Base Address and Bus Range onto MMIO configuration base Address MSR register. */ - MsrReg = CONFIG_MMCONF_BASE_ADDRESS | (8 << 2) | 1; + + MsrReg = CONFIG_MMCONF_BASE_ADDRESS | (LibAmdBitScanReverse (CONFIG_MMCONF_BUS_NUMBER) << 2) | 1; LibAmdMsrWrite (0xC0010058, &MsrReg, &StdHeader); /*

1 0

[commit] r6573 - trunk/src/mainboard/amd/persimmon
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:10:20 2011 New Revision: 6573 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6573 Log: 1) Use D18F1xF4 VGA Enable to simplify legacy video I/O support. 2) Extend PCI MMIO limit from dfffffff to fecfffff. 3) Add AMD recommended non-posted mapping for SB800 legacy devices. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/mainboard/amd/persimmon/agesawrapper.c Modified: trunk/src/mainboard/amd/persimmon/agesawrapper.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/agesawrapper.c Sun May 15 23:07:43 2011 (r6572) +++ trunk/src/mainboard/amd/persimmon/agesawrapper.c Sun May 15 23:10:20 2011 (r6573) @@ -85,38 +85,39 @@ PCI_ADDR PciAddress; AMD_CONFIG_PARAMS StdHeader; - /* Enable MMIO on AMD CPU Address Map Controller */ - - /* Start to set MMIO 0000A0000-0000BFFFF to Node0 Link0 */ + /* Enable legacy video routing: D18F1xF4 VGA Enable */ + PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0xF4); + PciData = 1; + LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); + + /* The platform BIOS needs to ensure the memory ranges of SB800 legacy + * devices (TPM, HPET, BIOS RAM, Watchdog Timer, I/O APIC and ACPI) are + * set to non-posted regions. + */ PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0x84); - PciData = 0x00000B00; + PciData = 0x00FEDF00; // last address before processor local APIC at FEE00000 + PciData |= 1 << 7; // set NP (non-posted) bit LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0x80); - PciData = 0x00000A03; - LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); - - /* Set TOM-DFFFFFFF to Node0 Link0. */ + PciData = (0xFED00000 >> 8) | 3; // lowest NP address is HPET at FED00000 + LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); + + /* Map the remaining PCI hole as posted MMIO */ PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0x8C); - PciData = 0x00DFFF00; + PciData = 0x00FECF00; // last address before non-posted range LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); LibAmdMsrRead (0xC001001A, &MsrReg, &StdHeader); MsrReg = (MsrReg >> 8) | 3; PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0x88); PciData = (UINT32)MsrReg; LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); - /* Set E0000000-FFFFFFFF to Node0 Link0 with NP set. */ - PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0xBC); - PciData = 0x00FFFF00 | 0x80; - LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); - PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0xB8); - PciData = (PCIE_BASE_ADDRESS >> 8) | 03; - LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); - /* Start to set PCIIO 0000-FFFF to Node0 Link0 with ISA&VGA set. */ + + /* Send all IO (0000-FFFF) to southbridge. */ PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0xC4); PciData = 0x0000F000; LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); PciAddress.AddressValue = MAKE_SBDFO (0, 0, 0x18, 1, 0xC0); - PciData = 0x00000013; + PciData = 0x00000003; LibAmdPciWrite(AccessWidth32, PciAddress, &PciData, &StdHeader); Status = AGESA_SUCCESS; return (UINT32)Status;

1 0

[commit] r6572 - trunk/src/mainboard/amd/persimmon
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:07:43 2011 New Revision: 6572 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6572 Log: 1) Set I/O APIC ID according to BKDG recommendation 2) Correct I/O APIC ID reported by mptable Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/mainboard/amd/persimmon/acpi_tables.c trunk/src/mainboard/amd/persimmon/get_bus_conf.c trunk/src/mainboard/amd/persimmon/mptable.c Modified: trunk/src/mainboard/amd/persimmon/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/acpi_tables.c Sun May 15 23:06:30 2011 (r6571) +++ trunk/src/mainboard/amd/persimmon/acpi_tables.c Sun May 15 23:07:43 2011 (r6572) @@ -64,7 +64,7 @@ current = acpi_create_madt_lapics(current); /* Write SB800 IOAPIC, only one */ - current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, 2, + current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current, CONFIG_MAX_CPUS, IO_APIC_ADDR, 0); current += acpi_create_madt_irqoverride((acpi_madt_irqoverride_t *) Modified: trunk/src/mainboard/amd/persimmon/get_bus_conf.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/get_bus_conf.c Sun May 15 23:06:30 2011 (r6571) +++ trunk/src/mainboard/amd/persimmon/get_bus_conf.c Sun May 15 23:07:43 2011 (r6572) @@ -138,7 +138,7 @@ /* I/O APICs: APIC ID Version State Address */ bus_isa = 10; - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; + apicid_base = CONFIG_MAX_CPUS; //#if CONFIG_LOGICAL_CPUS==1 // apicid_base = get_apicid_base(1); //#endif Modified: trunk/src/mainboard/amd/persimmon/mptable.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/mptable.c Sun May 15 23:06:30 2011 (r6571) +++ trunk/src/mainboard/amd/persimmon/mptable.c Sun May 15 23:07:43 2011 (r6572) @@ -69,7 +69,7 @@ dword |= (pm_ioread(0x35) & 0xFF) << 8; dword |= (pm_ioread(0x36) & 0xFF) << 16; dword |= (pm_ioread(0x37) & 0xFF) << 24; - smp_write_ioapic(mc, apicid_sb800, 0x11, dword); + smp_write_ioapic(mc, apicid_sb800, 0x21, dword); for (byte = 0x0; byte < sizeof(intr_data); byte ++) { outb(byte | 0x80, 0xC00);

1 0

[commit] r6571 - trunk/src/cpu/amd/agesa_wrapper/family14
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:06:30 2011 New Revision: 6571 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6571 Log: Correct the number of MCA error reporting banks cleared. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c Modified: trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c ============================================================================== --- trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c Sun May 15 23:01:42 2011 (r6570) +++ trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c Sun May 15 23:06:30 2011 (r6571) @@ -93,7 +93,7 @@ /* zero the machine check error status registers */ msr.lo = 0; msr.hi = 0; - for (i = 0; i < 5; i++) { + for (i = 0; i < 6; i++) { wrmsr(MCI_STATUS + (i * 4), msr); }

1 0

[commit] r6570 - trunk/src/cpu/amd/agesa_wrapper/family14
by repository service 15 May '11

15 May '11

Author: mjones Date: Sun May 15 23:01:42 2011 New Revision: 6570 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6570 Log: 1) Initialize BSP fixed MTRRs to match AP fixed MTRR initialization. 2) Remove coreboot variable MTRR initialization because AMD reference code handles it. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c Modified: trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c ============================================================================== --- trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c Fri May 13 08:25:16 2011 (r6569) +++ trunk/src/cpu/amd/agesa_wrapper/family14/model_14_init.c Sun May 15 23:01:42 2011 (r6570) @@ -62,6 +62,7 @@ u8 i; msr_t msr; + int msrno; struct node_core_id id; #if CONFIG_LOGICAL_CPUS == 1 u32 siblings; @@ -70,12 +71,24 @@ // id = get_node_core_id(read_nb_cfg_54()); /* nb_cfg_54 can not be set */ // printk(BIOS_DEBUG, "nodeid = %02d, coreid = %02d\n", id.nodeid, id.coreid); - /* Turn on caching if we haven't already */ - x86_enable_cache(); - amd_setup_mtrrs(); - x86_mtrr_check(); - - disable_cache(); + disable_cache (); + /* Enable access to AMD RdDram and WrDram extension bits */ + msr = rdmsr(SYSCFG_MSR); + msr.lo |= SYSCFG_MSR_MtrrFixDramModEn; + wrmsr(SYSCFG_MSR, msr); + + // BSP: make a0000-bffff UC, c0000-fffff WB, same as OntarioApMtrrSettingsList for APs + msr.lo = msr.hi = 0; + wrmsr (0x259, msr); + msr.lo = msr.hi = 0x1e1e1e1e; + for (msrno = 0x268; msrno <= 0x26f; msrno++) + wrmsr (msrno, msr); + + /* disable access to AMD RdDram and WrDram extension bits */ + msr = rdmsr(SYSCFG_MSR); + msr.lo &= ~SYSCFG_MSR_MtrrFixDramModEn; + wrmsr(SYSCFG_MSR, msr); + enable_cache (); /* zero the machine check error status registers */ msr.lo = 0; @@ -84,8 +97,6 @@ wrmsr(MCI_STATUS + (i * 4), msr); } - enable_cache(); - /* Enable the local cpu apics */ setup_lapic();

1 0

U-Boot-x86 / coreboot Integration
by Graeme Russ 15 May '11

15 May '11

Hi All, I figured it might be best to start a new, clean thread dealing with the technical design aspects of bootstrapping U-Boot from coreboot. I am extremely excited about this as the x86 U-Boot maintainer, but even more so by the idea of two very mature and respected FLOSS projects potentially becoming greater than the sum of their parts :) OK, enough with the warm and fuzzies. Lets look first at a few facts (as I understand them - please feel free to correct me): - U-Boot is a bootloader for embedded systems - A market segment dominated by ARM, PPC et al - i.e. NOT x86 - coreboot is a 'BIOS' replacement for mainstream PC's - A market segment dominated by x86 - Both are principally designed as 'primary bootloaders' - i.e. intended to be executed at CPU reset and responsible for low level hardware initialisation - U-Boot has no support for modern x86 PC hardware (North and South bridges, Dual-Core x86 CPUs, microcode, ACPI, APM etc) - coreboot is 'dumb' (No command line, scripting etc) As I understand it you build a 'payload' into the coreboot image which coreboot simply runs after it has performed necessary low-level hardware initialisation - U-Boot is 'smart' (command line, scripting, network support, environment variables etc) but currently lacks the ability to perform low level hardware initialisation of x86 PC hardware - coreboot launches a 'payload' which is (typically) an ELF executable linked to 'libpayload'. libpayload provides access to some primitive libc functionality, I/O and coreboot generated data structures - Our primary target OS is GNU/Linux (of course!) - The majority of U-Boot and coreboot is licensed under the 'GPLv2 or (at your option) any later version' So coreboot and U-Boot are a good complement to each other so bringing U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the politics ;) - The U-Boot source 'must' be self contained - No external libraries. Incorporating license compatible source is OK - coreboot payloads should be in ELF (linked to libpayload) - There should be minimal intrusion into the core U-Boot build scripts (Makefiles, mk.configs etc) - I would assume the same applies to coreboot build files as well. Hacking the U-Boot x86 specific build files should be fine - Everything should 'just work' with a recent GNU toolchain (gcc, binutils etc) - U-Boot relocates to 'Top of RAM' - This is a fundamental architectural design and not x86 specific. This feature should be retained for consistency with other U-Boot arches - Do we care about legacy BIOS support (SeaBIOS) for now (I think not)? So, a few questions - How much of libpayload would we need to bring into U-Boot to provide bare minimal payload delivery? U-Boot already contains it's own minimal libc routines. - How do we get VGA and USB keyboard support working? Do other U-Boot boards implement console on anything other than serial? - Can we add relocation support to the coreboot ELF loader? - Does coreboot relocate into RAM? If so, what is the target address? What guarantee is there that the target address is valid? - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy? - Is it worth playing around with segment registers to 'relocate' U-Boot - What hardware should be initialised in coreboot and what should be initialised in U-Boot? (political question ;) - What about Chipset Microcode (CMC) - What about System Management Mode (SMM) I think a good start would be to create a new U-Boot target which includes a stripped down libpayload in the U-Boot source. This target can exclude most of the assembler startup code (resetvec.S, start16.S, start.S). I assume the coreboot ELF loader (or libpayload) takes care of setting up the C environment (stack etc). We can start with U-Boot linked to a fixed location in RAM and skip relocations then work on either extending coreboot to perform relocation fixups or have U-Boot perform the fixups based on RAM information read from cbtable >From there, we can start to add device support (USB, video, PCI, IDE/SATA etc) It's getting late, so I'll stop now. Hopefully this gives a good design platform to start from Regards, Graeme P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you are not on the coreboot ml, you emails will get bounced to a moderator :(

5 19

How long will take to add coreboot support for my motherboard?
by Андрей Клаус 15 May '11

15 May '11

Hello everybody, I'm a newbe in this question. And english is not my native language. So, sorry for stupid and smooth questions.. I have a motherboard (epox 9NPA3I / 9NPA3J / 9NPAJ-3 / 9NPA3 Ultra Series) which is not supported 4GB memory.. at least in 4x1GB variant. I thinked may be it is software/bios problem. I updated bios to last version, still nothing. I thinked about coreboot (always wanted to try it). Unfortunatly, my motherboard is not in supported list. But looks like my chipset (CK804) and my superio (F71872F/FG) are in supported list. I have small expirience in C (about 1 year, about 5 years ago). So, i thinked about the trying to add support for my motherboard. My 1st question is: how long will take for proffessional coreboot developer to add support of my motherboard? I think i'll may be spend 5-10 times more. If for professional it will take up to 4 hours, i think i'll try. If not - i'll just leave an idea and will return memory. 2nd question (if 1st will positive, but anyway..): where should i start? 3rd question: actually, superiotool said me this (and is that ok?): #superiotool -d superiotool r5050 Found Fintek F71872F/FG / F71806F/FG (vid=0x3419, id=0x4103) at 0x4e No dump available for this Super I/O Thank you, guys. Andrey.

1 0

Hardware donation for porting Coreboot / FlashROM
by Yogev Ezra 14 May '11

14 May '11

Hello everyone, My name is Yogev Ezra from Green Gadgets Ltd, Israel ( http://www.greengadgets.co.il/) Our company specializes in assembly, integration and sales of small fanless computers, thin clients and industrial systems. We have two systems that we are willing to donate for porting Coreboot / FlashROM on them: 1. DM&P / ICOP eBox-3300MX thin client / nettop (based on Vortex86MX CPU that is x86 compatible - Pentium I MMX clone) Product page is available at: http://www.compactpc.com.tw/ebox-3300MX.htm CPU details are here: http://www.dmp.com.tw/tech/vortex86mx/ 2. Compulab Fit-PC2 nettop (Intel Atom Z510 / Z530 CPU + US15W chipset). Product page at: http://www.fit-pc.com/web/fit-pc2/fit-pc2-specifications/ Some datasheets are available here: http://fit-pc2.com/wiki/index.php/Documentation and here: http://www.compulab.co.il/fitpc2/html/fitpc2-developer.py Why are we doing that? --- Having more choices for BIOS will benefit the customers and increase possible usage options. Freeware BIOS will also mean eventually cheaper systems. In addition, the factory BIOS in both systems has some issues that we hope to solve with Coreboot: a) The eBox-3300MX has ROM chip big enough (2MB) to start a small OS directly from BIOS, so no external storage is needed (I am thinking of KolibriOS). The factory BIOS can support this option, but the manufacturer requests extra fee which is too high to justify it. b) Fit-PC2 occasionally does not recognize SSD disks on boot. Normal "mechanical" hard disks are always recognized fine. We believe the problem is in factory BIOS or in bridge-chip BIOS (US15W chipset does not have native SATA port so Fit-PC2 is using Marvell 88SA8052 PATA-to-SATA bridge chip). The manufacturer Compulab does not even acknowledge the problem, yet alone solve it. Q&A and general terms: 1) The manufacturers of both systems currently do not support, endorse or allow using Coreboot. We are doing this as our own initiative. Installing Coreboot instead of factory BIOS will most likely void the manufacturer warranty. 2) We do not try this ourselves because flash ROM chips in both systems are soldered, and we just do not have the qualification and equipment for de-soldering / re-soldering the chips. We already "bricked" a few systems in the past, so we prefer to concentrate on our own work and let the professionals try that. 3) We can supply non-NDA datasheets and more info on request. To receive NDA datasheets, you will have to sign this directly with manufacturers. Not sure if manufacturers will agree to that, when you tell them what it's needed for (Coreboot)... 4) The systems we are donating cost us (a lot of) money, so we would like them to get into "good" hands, of people that actually can invest time in porting Coreboot/FlashROM to those systems. If you just want free hardware, please do not bother. We can donate up to 5 units of each system, in 3 phases: Phase I - one unit, should go to someone very knowledgeable to start the porting from scratch. JTAG knowledge and JTAG programmer is a big plus (eBox-3300MX has on-board JTAG port. Not sure about Fit-PC2 but probably it does have too). Phase II - two more units, once the porting becomes WIP on Supported Mainboards list (http://www.coreboot.org/Supported_Motherboards), to people who can help the person from Phase I to fix major bugs Phase III - two more units to two more people, to fix minor bugs once major bugs are fixed The reason we won't donate more than one unit from the beginning is because of big hardware costs that we just cannot bear, so we would like to see at least some progress before we can allow to donate more units. Interested persons that are willing to work on Phase I (and have the required skills and free time to actually work on this), are welcome to e-mail me. Other comments are also welcome. Best regards, Yogev Ezra Green Gadgets

4 5

← Newer
1
...
8
9
10
11
12
13
14
...
17
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 May 2011