coreboot January 2011

coreboot@coreboot.org

65 participants
299 discussions

Re: [coreboot] DL145 G1 with dual dualcore CPU using coreboot ?
by Oskar Enoksson 28 Sep '11

28 Sep '11

Oskar Enoksson wrote: > Myles Watson wrote: > >>> I think Myles was right, there is a i2c mux in this server that somehow >>> multiplexes DIMM devices on the i2c bus. I was able to guess which i2c >>> ports contain the DIMM info, and which port is the mux, then added the >>> mux to devicetree.cb and the DIMM ports under it. Now I'm able to use >>> memory from both CPU's, at least for the combination of DIMM's I have >>> (2x2x1GB and 2x2x512MB). >>> >>> >> I'm glad it worked out! >> >> >>> So I'm basically able to use these servers now. I would love to have >>> ACPI and Cool'nQuiet of course, perhaps I'll try to do that later. >>> >>> Thanks very much for all help! If you want me to commit the new >>> mainboard to your svn repository let me know. >>> >>> >> Yes, please. If you'll send your latest patch with a Signed-off-by: line, >> I'll take it from there. >> >> Thanks, >> Myles >> >> > I hope this file is the way you want it. I did "svn cp > src/mainboard/tyan/s2881 src/mainboard/hp/dl145_g1" and then modified > the files, then "svn diff src/mainboard" so I assume you should do the > same svn cp operation, then apply my patch, then commit to retain the > original files' history. > I have fixed several problems and now it boots reliably for both and older dual Opteron 248 server and an upgraded dual Opteron 280 server. memtest86+ doesn't work, but according to another mailinglist thread memtest cannot handle tables in high memory, so that seems to be a memtest issue. Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.

6 12

[PATCH] More explicite and straight way to set seed
by Bao, Zheng 03 Jun '11

03 Jun '11

More explicite and straight way to set seed. Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Index: src/northbridge/amd/amdmct/mct/mctsrc.c =================================================================== --- src/northbridge/amd/amdmct/mct/mctsrc.c (revision 6135) +++ src/northbridge/amd/amdmct/mct/mctsrc.c (working copy) @@ -1023,13 +1023,9 @@ dev = pDCTstat->dev_dct; for (index = 0x50; index <= 0x52; index ++) { - val = Get_NB32_index_wait(dev, index_reg, index); - val |= (FenceTrnFinDlySeed & 0x1F); + val = (FenceTrnFinDlySeed & 0x1F); if (index != 0x52) { - val &= ~(0xFF << 8); - val |= (val & 0xFF) << 8; - val &= 0xFFFF; - val |= val << 16; + val |= val << 8 | val << 16 | val << 24; } Set_NB32_index_wait(dev, index_reg, index, val); } Index: src/northbridge/amd/amdmct/mct_ddr3/mctsrc.c =================================================================== --- src/northbridge/amd/amdmct/mct_ddr3/mctsrc.c (revision 6135) +++ src/northbridge/amd/amdmct/mct_ddr3/mctsrc.c (working copy) @@ -972,13 +972,9 @@ */ dev = pDCTstat->dev_dct; for (index = 0x50; index <= 0x52; index ++) { - val = Get_NB32_index_wait(dev, index_reg, index) & ~0xFF; - val |= (FenceTrnFinDlySeed & 0x1F); + val = (FenceTrnFinDlySeed & 0x1F); if (index != 0x52) { - val &= ~(0xFF << 8); - val |= (val & 0xFF) << 8; - val &= 0xFFFF; - val |= val << 16; + val |= val << 8 | val << 16 | val << 24; } Set_NB32_index_wait(dev, index_reg, index, val); }

3 2

[PATCH] RS690 code booting RS740 with ECS A740GM-M
by Ivaylo Valkov 09 May '11

09 May '11

Adds RS740 HT and internal graphics PCI ids. Adds support for RS740 in RS690 code (some of the fam10 code from RS780). Adds support for ECS A740GM-M. This definitely needs more patches and fine-tuning. Only tested on RS740. Signed-off-by: Ivaylo Valkov <ivaylo(a)e-valkov.org> --- Hello all, And thank you for all the work you have done so far. This is kind of long e-mail, so for the impatient - with these patches I am able to initialize the RS740 chipset on the ECS A740GM-M motherboard and boot GNU/Linux (with Xorg), but the code definitely needs more fine-tuning and patching. All my hardware died recently, so I bought two identical ECS A740GM-M [1] replacement boards with AMD RS740/740G chipset as an opportunity to help the coreboot project gather some information. The requested information for flashrom and the RS740 chipset is attached. One thing led to another and I've gone a lot further - the board seems usable. Flashrom works on the board. The flash chip is recognised as MX25L8005, but it is actually [2] MX25L8006. [3] In spite of that I was able to flash it and boot the proprietary BIOS and coreboot. I've experienced some CMOS checksum errors with the proprietary BIOS after flashing, but everything worked fine after setting the date. This does not happen always and I can't see a pattern when it does. Should I post the flashrom related information on the flashrom mailing list? With flashrom working and the information on this list (and few other places) that the RS740 is RS690 with new graphics I decided to test the RS690 code on the board. So, after nearly a month of cut-and-paste from mahogany_fam10 and dmb690t, new code in RS690, borrowed from RS780, ACPI from mahogany_fam10 for the board and some modifications I ended up with something usable. The CPU is Sempron 140 (AM3/AM2+ socket). I have some basic and blurry understanding of the boot process. I do not know why exactly all that I've done worked. It is fair to say that I have read almost zero documentation. All was achieved only by reading the available code and observing the logic. Maybe it wasn't the smartest and safest thing to do, but worth it. So carefully review the code. Some of it is there so I could build. It might be irrelevant. Patches are attached. I used a cmos.layout from mahogany_fam10 to build, but images with enabled CONFIG_USE_OPTION_TABLE (use CMOS/NVRAM values instead of hard coded ones) in menuconfig do not boot at all - not even single serial line of output. With recent changes and the move of CMOS to CBFS I can't build with that option. I am able to boot GNU/Linux. USB, network, sound, ATA and SATA are working. PCI worked with external graphic and network card. PCIe is not tested. The master and stable releases of SeaBIOS hang when there is a USB mouse connected after printing "USB mouse initialized". USB works fine under GNU/Linux. HT is initialized to 200MHz. The lspci output (also attached) after coreboot loads, shows that 1.6GHz link frequency is possible. The documented limit for RS690 is 1GHz. The RS780 code is implemented differently, so it has k8 and fam10 support. Do you think it will be possible to use something from RS780 code? I am not confident and competent to make the changes myself, but I am willing to test patches (any). The lspci output for the board with coreboot running differs(in places). I think it is ACPI and devicetree.cb related. Don't know how to fix it right now. After coreboot initializes the board, the CPU has two states - 1.9 GHz and 2.7GHz. With proprietary BIOS the CPU can do two more - 1.5GHz and 800MHz. That is ACPI issue, righ? Before adding ACPI the only possible frequency was 2.7GHz. The code that prints the CPU revision (in get_cpu_revision) is taken from RS780. I think it prints (only that!) wrong revision - "K8_10" instead of "Fam 10". It seems it should be "eax <= 0x100fff" instead of "eax <= 0x100f00", but as I've said I didn't read enough documentation. I've extracted a VGA BIOS image from the proprietary BIOS and the internal graphics card worked. Both DVI and VGA connectors work. Xorg loads, but if the resolution is higher than or equal to 1024x768 the screen flickers and I see horizontal lines. [4] When the display is refreshed (key press, mouse move, by programs) it is awful. [5] For lower resolutions it is not noticeable or even missing. This is tested on deblobed Linux-libre kernel only, and the drivers do not load the binary-blob firmware for 3D acceleration. Is it possible to initialize the internal graphics on RS690/RS740 from coreboot code and use VGA BIOS image from SeaBIOS? Like it is done for the M2V-MX SE board? Yes I know it uses VIA chipset and it has documentation. I guess what I am asking is, is it there enough documentation released by AMD to make it work. I've hacked a PCI header for the VGA BIOS image from SeaBIOS, so it can be loaded by coreboot (vendor/device ID complains). The ROM is loaded, but SeaBIOS hangs. Not that I was expecting to just work. There are microcode patches for some CPUs that are non-free binary-blobs (examine their license headers). Is it possible to make loading such microcode configurable? I am unable to build the fam10 code without a microcode filename. I understand that AMD (and other companies) might not want to release such information for various reasons, but I prefer to use "crippled" CPU instead of non-free microcode, when I am running free software BIOS. Do I really need them for Sempron anyway? It works without them. Didn't notice any difference in performance with them. Not that the current state of the board can be used for measuring performance. The work-around I am using right now is zero-filled microcode patch file in the board directory, that does nothing. Images of the board and the chips can be found on my "web site" [6]. I've copied the copyright notices from files that had such and I've used code from. For the rest I've put a comment pointing to the file I've borrowed from. Hope that is the right way to do it. Unfortunately the code I used restricts me to GPLv2 only, I prefer GPLv2(or later). What is the policy on GPLv3 (or later) code for that matter? Just thinking for possible future contributions. P.S. This is a lot of information (and issues). If anything has to go in the issue tracker I will do it. [1] http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?CategoryID=1&D… [2] http://e-valkov.org/coreboot/ecs-a740gm-m-bios-chip.jpg [3] http://www.mxic.com.tw/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Inde… [4] http://e-valkov.org/coreboot/video-card-1.ogv [5] http://e-valkov.org/coreboot/video-card-2.ogv [6] http://e-valkov.org/coreboot/

4 10

[patch] fix Windows 7 checked build assert caused by FADT length/revision inconsistency
by Scott Duplichan 18 Apr '11

18 Apr '11

Running a checked build of Windows is needed for understanding its various BIOS related BSODs. Win7 checked build complains when running coreboot+seabios: FADT revision inconsistent with length. Revision: 0x1 Length: 0xf4 Expected Length: 0x74 The following patch solves the problem. Tested on Mahogany_fam10 only. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Index: src/southbridge/nvidia/ck804/ck804_fadt.c =================================================================== --- src/southbridge/nvidia/ck804/ck804_fadt.c (revision 5978) +++ src/southbridge/nvidia/ck804/ck804_fadt.c (working copy) @@ -20,10 +20,11 @@ memcpy(header->signature, "FACP", 4); #ifdef LONG_FADT header->length = 244; + header->revision = 3; #else header->length = 0x74; + header->revision = 1; #endif - header->revision = 1; memcpy(header->oem_id, "CORE ", 6); memcpy(header->oem_table_id, "CB-FADT ", 8); memcpy(header->asl_compiler_id, "IASL", 4); Index: src/mainboard/iwill/dk8_htx/fadt.c =================================================================== --- src/mainboard/iwill/dk8_htx/fadt.c (revision 5978) +++ src/mainboard/iwill/dk8_htx/fadt.c (working copy) @@ -19,7 +19,7 @@ memset((void *)fadt,0,sizeof(acpi_fadt_t)); memcpy(header->signature,"FACP",4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id,OEM_ID,6); memcpy(header->oem_table_id,"COREBOOT",8); memcpy(header->asl_compiler_id,ASLC,4); Index: src/mainboard/asrock/939a785gmh/fadt.c =================================================================== --- src/mainboard/asrock/939a785gmh/fadt.c (revision 5978) +++ src/mainboard/asrock/939a785gmh/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/kontron/kt690/fadt.c =================================================================== --- src/mainboard/kontron/kt690/fadt.c (revision 5978) +++ src/mainboard/kontron/kt690/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/gigabyte/ma78gm/fadt.c =================================================================== --- src/mainboard/gigabyte/ma78gm/fadt.c (revision 5978) +++ src/mainboard/gigabyte/ma78gm/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/gigabyte/ma785gmt/fadt.c =================================================================== --- src/mainboard/gigabyte/ma785gmt/fadt.c (revision 5978) +++ src/mainboard/gigabyte/ma785gmt/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/amd/mahogany/fadt.c =================================================================== --- src/mainboard/amd/mahogany/fadt.c (revision 5978) +++ src/mainboard/amd/mahogany/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/amd/pistachio/fadt.c =================================================================== --- src/mainboard/amd/pistachio/fadt.c (revision 5978) +++ src/mainboard/amd/pistachio/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/amd/dbm690t/fadt.c =================================================================== --- src/mainboard/amd/dbm690t/fadt.c (revision 5978) +++ src/mainboard/amd/dbm690t/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/amd/serengeti_cheetah/fadt.c =================================================================== --- src/mainboard/amd/serengeti_cheetah/fadt.c (revision 5978) +++ src/mainboard/amd/serengeti_cheetah/fadt.c (working copy) @@ -19,7 +19,7 @@ memset((void *)fadt,0,sizeof(acpi_fadt_t)); memcpy(header->signature,"FACP",4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id,OEM_ID,6); memcpy(header->oem_table_id,"COREBOOT",8); memcpy(header->asl_compiler_id,ASLC,4); Index: src/mainboard/amd/mahogany_fam10/fadt.c =================================================================== --- src/mainboard/amd/mahogany_fam10/fadt.c (revision 5978) +++ src/mainboard/amd/mahogany_fam10/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/amd/tilapia_fam10/fadt.c =================================================================== --- src/mainboard/amd/tilapia_fam10/fadt.c (revision 5978) +++ src/mainboard/amd/tilapia_fam10/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/amd/serengeti_cheetah_fam10/fadt.c =================================================================== --- src/mainboard/amd/serengeti_cheetah_fam10/fadt.c (revision 5978) +++ src/mainboard/amd/serengeti_cheetah_fam10/fadt.c (working copy) @@ -40,7 +40,7 @@ memset((void *)fadt,0,sizeof(acpi_fadt_t)); memcpy(header->signature,"FACP",4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id,OEM_ID,6); memcpy(header->oem_table_id,"COREBOOT",8); memcpy(header->asl_compiler_id,ASLC,4); Index: src/mainboard/iei/kino-780am2-fam10/fadt.c =================================================================== --- src/mainboard/iei/kino-780am2-fam10/fadt.c (revision 5978) +++ src/mainboard/iei/kino-780am2-fam10/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/via/epia-m700/fadt.c =================================================================== --- src/mainboard/via/epia-m700/fadt.c (revision 5978) +++ src/mainboard/via/epia-m700/fadt.c (working copy) @@ -30,7 +30,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, "VX800 ", 6); memcpy(header->oem_table_id, "LNXBACPI", 8); memcpy(header->asl_compiler_id, "LXB", 8); Index: src/mainboard/via/vt8454c/fadt.c =================================================================== --- src/mainboard/via/vt8454c/fadt.c (revision 5978) +++ src/mainboard/via/vt8454c/fadt.c (working copy) @@ -29,7 +29,7 @@ memset((void *) fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, "CX700 ", 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, "CORE", 4); Index: src/mainboard/via/epia-m/fadt.c =================================================================== --- src/mainboard/via/epia-m/fadt.c (revision 5978) +++ src/mainboard/via/epia-m/fadt.c (working copy) @@ -31,7 +31,7 @@ memset((void *)fadt,0,sizeof(acpi_fadt_t)); memcpy(header->signature,"FACP",4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id,OEM_ID,6); memcpy(header->oem_table_id,"COREBOOT",8); memcpy(header->asl_compiler_id,ASLC,4); Index: src/mainboard/via/epia-n/fadt.c =================================================================== --- src/mainboard/via/epia-n/fadt.c (revision 5978) +++ src/mainboard/via/epia-n/fadt.c (working copy) @@ -33,7 +33,7 @@ memset((void *)fadt,0,sizeof(acpi_fadt_t)); memcpy(header->signature,"FACP",4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id,OEM_ID,6); memcpy(header->oem_table_id,"COREBOOT",8); memcpy(header->asl_compiler_id,ASLC,4); Index: src/mainboard/jetway/pa78vm5/fadt.c =================================================================== --- src/mainboard/jetway/pa78vm5/fadt.c (revision 5978) +++ src/mainboard/jetway/pa78vm5/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/technexion/tim8690/fadt.c =================================================================== --- src/mainboard/technexion/tim8690/fadt.c (revision 5978) +++ src/mainboard/technexion/tim8690/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/technexion/tim5690/fadt.c =================================================================== --- src/mainboard/technexion/tim5690/fadt.c (revision 5978) +++ src/mainboard/technexion/tim5690/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4); Index: src/mainboard/intel/eagleheights/fadt.c =================================================================== --- src/mainboard/intel/eagleheights/fadt.c (revision 5978) +++ src/mainboard/intel/eagleheights/fadt.c (working copy) @@ -56,7 +56,7 @@ memset((void *) fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, "CORE ", 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, "CORE", 4); Index: src/mainboard/asus/m4a785-m/fadt.c =================================================================== --- src/mainboard/asus/m4a785-m/fadt.c (revision 5978) +++ src/mainboard/asus/m4a785-m/fadt.c (working copy) @@ -52,7 +52,7 @@ memset((void *)fadt, 0, sizeof(acpi_fadt_t)); memcpy(header->signature, "FACP", 4); header->length = 244; - header->revision = 1; + header->revision = 3; memcpy(header->oem_id, OEM_ID, 6); memcpy(header->oem_table_id, "COREBOOT", 8); memcpy(header->asl_compiler_id, ASLC, 4);

3 4

Invite: Silicon Valley Coreboot Hackathon
by David Hendricks 12 Mar '11

12 Mar '11

Stefan mentioned that he knows several people who he has worked with in the area, and we're thinking it would be fun to get everyone together for a day of hacking on Coreboot and related projects such as Flashrom and SeaBIOS. So, I'd like to invite everyone to Google's beautiful campus in Mountain View for a day of Coreboot hacking, board porting, BIOS flashing, etc. We'll set a tentative date for Saturday the 29th of this month from noon 'till 8pm. We also have FlexyICE ROMulators and Dediprog SPI flash programmers so folks can worry less about bricking their system. Maybe Stefan can whip up a tutorial for newbies if there is particular interest in a specific area. If this sounds like something you'd like to participate in, please fill out the registration form at the URL below. It will help us to ensure we have adequate facilities reserved, equipment ready, visitor badges printed, and technically prepared for the topics of interest. We'll also send confirmation with detailed instructions on how to find the building / conference room to those who register. Registration form: https://spreadsheets.google.com/viewform?formkey=dGRab2s1VHRKNzRDX19pTVVrTj… -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

5 11

Re: [coreboot] [PATCH] SECC Pentium 2/3 users are gonna love this
by Keith Hui 02 Mar '11

02 Mar '11

> > Please don't gzip patches, it lowers the chance of someone reviewing > them to zero ;-) I figured if we're coding at this level, gzip won't be a hurdle. I announced it up front, didn't I? :p > > There is 65x microcode in the model_67x directory, and it's not split up > into single files as for the other CPUs. > The microcodes are static and are not supposed to change, our CPU drivers are grouped by family, and the microcodes are going to be included one after another in one place anyway even when made separate, so why have 5 files for 5 microcodes in the 67x family for example when one will do? Of course I retained the comments therein that marks the microcodes and the processors they're intended for. To put things in perspective, the microcode data we get from Intel has hundreds of them all in one file. > + if (cpuid_res.ebx != 0x756e6547 || cpuid_res.edx != 0x49656e69 || > cpuid_res.ecx != 0x6c65746e) { > + printk(BIOS_INFO, "Not 'GenuineIntel' Processor"); > + return 0; > + } > > This is not necessary. When model_6**_init() is executed, it's clear > already that this is an intel cpu. I'm not sure if the check for choosing the CPU driver to execute is on these CPUID signatures, or through some other fields. This check is carried from v1. I agree we can take a chance and take it out; we'll revisit when something breaks. :D > > +/* if (signature & 0x1000) { > + printk(BIOS_DEBUG,"Overdrive chip no L2 cache configuration\n"); > + return 0; > + } > + > + if (signature < 0x630 || signature >= 0x680) { > + printk(BIOS_DEBUG,"L2 cache on CPUID %x does not require > configuration\n", signature); > + return 0; > + }*/ > > I think this code should just be dropped That may change when (IF) we manage to get coreboot on a socket 8 board on which a Pentium II OverDrive processor sits. Again this piece is from the original code from v1. I agree the second signature check is not needed. > > Is it generally possible to move p6_configure_l2_cache to a generic > place, maybe to cpu/x86/cache ? > > +/*--- End L2 init code from corebbot v1 ---*/ > > I think this kind of comment is not needed. > That's a marker to help preserve my sanity. :-p > +static inline void strcpy(char *dst, char *src) > +{ > + while (*src) *dst++ = *src++; > +} > > I know I am the idiot who introduced this in a model_xxx_init.c file, > but maybe we should move it to lib/strcpy.c ? Well, 63x and 67x don't even need this; they don't support the processor brand string that 6bx do. Same with the fill_processor_name() function. I'll just take them out entirely. > > +static struct cpu_device_id cpu_table[] = { > + { X86_VENDOR_INTEL, 0x0650 }, > + { X86_VENDOR_INTEL, 0x0651 }, > + { X86_VENDOR_INTEL, 0x0652 }, > + { X86_VENDOR_INTEL, 0x0653 }, > + { X86_VENDOR_INTEL, 0x0671 }, > + { X86_VENDOR_INTEL, 0x0672 }, > + { X86_VENDOR_INTEL, 0x0673 }, > + { 0, 0 }, > +}; > > Instead of using a common driver, can two drivers use a common set of > shared functions instead? > It's already partially done. src/cpu/intel/model_67x/l2_cache.c (new in this patch) is linked in by model_65x driver too. Next prime suspect: fill_processor_name() in 6bx and a few other CPU models I'm no expert of. But 65x and 67x really are so similar that one driver can do both. Now is our end goal here to spin off model_63x/65x/66x/67x/68x/6ax/6bx all into their own CPU drivers when most of what's being done is duplicating code from model_6xx which is what they collectively once were? What's the rationale behind this need for split? I think a split should only be done when different initialization sequence are needed, eg. the special L2 initialization sequence for these SECC P6s. Same with motherboard models. When P2B-LS support matures I'd probably use the same directory for P2B-L and P2B-S support. They share the same circuit board anyway, and a -LS can emulate both by moving two jumpers. > +ifeq ($(CONFIG_USE_DCACHE_RAM),y) > +cpu_incs += $(src)/cpu/intel/car/cache_as_ram.inc > +endif > > This will break all targets except the ones you worked on. > I read this and thought, "I gotta run abuild." So I did. The errors I saw all seems to be k8/k10 targets and/or ACPI related. Even the entire P2B family that is in the tree passed abuild with this patch applied. Oh they haven't been migrated to CAR yet. Thanks Keith

6 19

coreboot certified hardware
by Carl-Daniel Hailfinger 02 Mar '11

02 Mar '11

Hi, I wonder if we want to establish something like the "Designed for Windows XP" or "Yes it runs with Netware" certificates? It would certainly be a nice marketing aid for vendors, and at the same time it would promote coreboot visibility. If there is interest in such an idea, we will have to decide which criteria have to be fulfilled to get such a certificate, and if the certificate has an expiry date and/or is bound to a specific svn revision. Off the top of my head, I can think of the following criteria: - coreboot+SeaBIOS works well enough to boot $ENTERPRISE_LINUX, $ENDUSER_LINUX and Windows 7 (Vista and XP as well?) - Nvidia and ATI graphics drivers (both free and closed) work if booted with a coreboot+SeaBIOS image? - Frequency scaling and the various suspend methods work - Soft poweroff works - IRQ routing and all PCI/PCIe/AGP/whatever slots work - Legacy ports (if present) work - Fans work well enough (temperature-based scaling if present in the "normal" BIOS) - Source for a working coreboot image (including the Kconfig settings for the board, and possibly NVRAM settings?) is available for free without NDA - Board port merged into coreboot svn - SeaBIOS source code is available - SeaBIOS code is merged into SeaBIOS git - flashrom works on the board (no lockdown) or there is a way to boot unlocked and run flashrom for your image of choice - At least some serial output (coreboot version) if a serial port (header) is present, otherwise... USB Debug? Floppy? LPC bus? POST card on port 82h? Did I forget something? Are some criteria useless? What would Jane User expect from a normal mainboard if she didn't know coreboot was running? Regards, Carl-Daniel -- http://www.hailfinger.org/

11 25

[RFC] [PATCH] Overclocking support for 939a785gmh
by Rudolf Marek 26 Feb '11

26 Feb '11

Hi all, Attached patch adds support for CMOS options which can alter DDR Memory, HT GPU, and Sideport Voltages. Also as a quick hack it can change CPU base frequency from 200MHz to something else. I think this would be nice to show on FOSDEM.It could be extended so not only CPU PLL is programmed but also PCIe etc, also one could adjust the DDR divisors so the memory runs still like on 200MHz (same for HT). Also FID could be changed, but this is not implemented yet. The CPU voltage changes are possible too. It is just a question of writing to SIO... boot_option = Fallback last_boot = Fallback ECC_memory = Disable baud_rate = 115200 debug_level = Info power_on_after_fail = Disable hw_scrubber = Disable nmi = Disable iommu = Enable interleave_chip_selects = Enable multi_core = Enable slow_cpu = off max_mem_clock = DDR400 cmos_defaults_loaded = Disable ht_voltage = 1.30V sideport_voltage = 1.82V gpu_voltage = 1.10V memory_voltage = 2.60V cpu_freq = 210MHz Although it is bit hackish I do Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz> If someone has similar/same board and has more time to work on this it would be very nice! Not sure If I will be able to prepare it to comittable state before FOSDEM. Thanks, Rudolf

2 3

[PATCH] RFC AMD powernow generation for pre fam 0fh
by Rudolf Marek 24 Feb '11

24 Feb '11

Hi all, This is RFC patch. It adds support for automatic PSS object generation for AMD pre fam Fh CPU. Those CPUs require a hardcoded table, which I managed to rewrite during one particularly boring flight. Too pity it is only for Opteron CPUs. Someone needs to finish the second PDF for All others Athlons and Semprons. It just adds the table to same place where is the fam0fh generator. To make the powernow work on my Asrock 939 board I had to enable undocumented bit1 in PM_Misc 67h of SB710. It looks like this bit is documented in SB600 and it is doing LDT_STOP toggle for C states (and for FID/VID). I remember I had to fix this toggle for VIA chipset too. It took me some time to figure it out. It helped that it started to work if the orig bios was booted and halted to S5. All search was to find out what register was not updated by coreboot). Whom to ask to fix the AMD documentation? It is unknown if the bit is necessary for fam 0fh or fam10h, question is if the second bit CC_en which says: "C State enable. This bit must be set in order to exercise the C state" should be enabled (it is for me with orig BIOS). Thanks, Rudolf

3 3

QA contribution
by Danila Sukharev 17 Feb '11

17 Feb '11

Hi there! I'm a QA guy interested in coreboot project. I have two mobos supported by coreboot; also I have some QA and dev skills (but mostly QA). I also have the ability to check the coreboot on some other mobos - I have them in my hands from time to time. How is it possible for me to start contributing the project in such a role? Is there some guide, some list of open tasks, or list of fixes pending review?.. I've looked over the site but have not found clear answer to my question. Thanks, -- Dan

6 14

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 2011