coreboot May 2011

coreboot@coreboot.org

62 participants
161 discussions

[PATCH] workaround for "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c"
by Scott Duplichan 20 May '11

20 May '11

The attached patch works around a Windows XP or Server 2003 setup failure where an error message such as: "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c" The value 805262864 varies, and is the physical address, in decimal, of one of the ACPI tables. Tested on Persimmon. Others abuild tested only. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Detailed explanation: The error message is displayed when a 1024 dword page table array used by setupldr runs out of space. This table is used for mapping various physical addresses, such as those of ACPI tables (a separate table identity maps the lower 16MB used by setupldr code and data). Setupldr only looks at ACPI tables (FACP) to determine make and model of the system. The make and model of the system is needed when setupldr scans the good/bad bios lists contained in txtsetup.sif. The good/bad bios lists are used to bypass installation of the ACPI enabled kernel on certain systems known to have ACPI problems. The code loop that scans the lists creates a new mapping each time it reads an ACPI table, and never frees mappings. The code uses FACP OEM ID to determine the system model. The code sequentially reads tables listed in the RSDT array until the FACP is found. Each read consumes one page table entry. If more that 4 tables precede the FACP in the RSDT array, the 1024 entry page table array will run out of space before the good/bad bios list processing completes. BIOS can work around this Windows XP/Server 2003 limitation by placing the FACP early in the RSDT array. Thanks, Scott

6 7

[commit] r6600 - in trunk/src/mainboard/amd: bimini_fam10 dbm690t inagua mahogany mahogany_fam10 persimmon pistachio serengeti_cheetah serengeti_cheetah_fam10 tilapia_fam10
by repository service 20 May '11

20 May '11

Author: Sduplichan Date: Fri May 20 02:06:09 2011 New Revision: 6600 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6600 Log: Move the ACPI FACP table to the front of the RSDT list. This is done to work around a Windows XP or Server 2003 setup failure where an error message such as: "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c" occurs. This change updates AMD reference board projects, but could applied to others as well. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/mainboard/amd/bimini_fam10/acpi_tables.c trunk/src/mainboard/amd/dbm690t/acpi_tables.c trunk/src/mainboard/amd/inagua/acpi_tables.c trunk/src/mainboard/amd/mahogany/acpi_tables.c trunk/src/mainboard/amd/mahogany_fam10/acpi_tables.c trunk/src/mainboard/amd/persimmon/acpi_tables.c trunk/src/mainboard/amd/pistachio/acpi_tables.c trunk/src/mainboard/amd/serengeti_cheetah/acpi_tables.c trunk/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c trunk/src/mainboard/amd/tilapia_fam10/acpi_tables.c Modified: trunk/src/mainboard/amd/bimini_fam10/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/bimini_fam10/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/bimini_fam10/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -127,6 +127,31 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* DSDT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; // it will used by fadt + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); + + /* FACS */ // it needs 64 bit alignment + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); + facs = (acpi_facs_t *) current; // it will be used by fadt + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* FADT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -219,31 +244,6 @@ } #endif - /* DSDT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; // it will used by fadt - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); - - /* FACS */ // it needs 64 bit alignment - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); - facs = (acpi_facs_t *) current; // it will be used by fadt - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* FADT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/dbm690t/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/dbm690t/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/dbm690t/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -129,6 +129,27 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* FACS */ + printk(BIOS_DEBUG, "ACPI: * FACS\n"); + facs = (acpi_facs_t *) current; + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* DSDT */ + printk(BIOS_DEBUG, "ACPI: * DSDT\n"); + dsdt = (acpi_header_t *)current; + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); + /* FADT */ + printk(BIOS_DEBUG, "ACPI: * FADT\n"); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -153,27 +174,6 @@ current += ssdt->length; acpi_add_table(rsdp, ssdt); - /* FACS */ - printk(BIOS_DEBUG, "ACPI: * FACS\n"); - facs = (acpi_facs_t *) current; - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* DSDT */ - printk(BIOS_DEBUG, "ACPI: * DSDT\n"); - dsdt = (acpi_header_t *)current; - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); - /* FADT */ - printk(BIOS_DEBUG, "ACPI: * FADT\n"); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/inagua/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/inagua/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/inagua/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -133,6 +133,31 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* DSDT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; // it will used by fadt + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); + + /* FACS */ // it needs 64 bit alignment + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); + facs = (acpi_facs_t *) current; // it will be used by fadt + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* FADT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -199,31 +224,6 @@ printk(BIOS_DEBUG, "ACPI: * SSDT for PState at %lx\n", current); - /* DSDT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; // it will used by fadt - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); - - /* FACS */ // it needs 64 bit alignment - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); - facs = (acpi_facs_t *) current; // it will be used by fadt - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* FADT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/mahogany/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/mahogany/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/mahogany/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -140,6 +140,27 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* FACS */ + printk(BIOS_DEBUG, "ACPI: * FACS\n"); + facs = (acpi_facs_t *) current; + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* DSDT */ + printk(BIOS_DEBUG, "ACPI: * DSDT\n"); + dsdt = (acpi_header_t *)current; + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); + /* FADT */ + printk(BIOS_DEBUG, "ACPI: * FADT\n"); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -205,27 +226,6 @@ } #endif - /* FACS */ - printk(BIOS_DEBUG, "ACPI: * FACS\n"); - facs = (acpi_facs_t *) current; - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* DSDT */ - printk(BIOS_DEBUG, "ACPI: * DSDT\n"); - dsdt = (acpi_header_t *)current; - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); - /* FADT */ - printk(BIOS_DEBUG, "ACPI: * FADT\n"); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/mahogany_fam10/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/mahogany_fam10/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/mahogany_fam10/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -126,6 +126,31 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* DSDT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; // it will used by fadt + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); + + /* FACS */ // it needs 64 bit alignment + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); + facs = (acpi_facs_t *) current; // it will be used by fadt + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* FADT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -218,31 +243,6 @@ } #endif - /* DSDT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; // it will used by fadt - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); - - /* FACS */ // it needs 64 bit alignment - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); - facs = (acpi_facs_t *) current; // it will be used by fadt - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* FADT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/persimmon/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/persimmon/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/persimmon/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -129,6 +129,31 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* DSDT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; // it will used by fadt + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); + + /* FACS */ // it needs 64 bit alignment + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); + facs = (acpi_facs_t *) current; // it will be used by fadt + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* FDAT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -193,31 +218,6 @@ printk(BIOS_DEBUG, "ACPI: * SSDT for PState at %lx\n", current); - /* DSDT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; // it will used by fadt - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); - - /* FACS */ // it needs 64 bit alignment - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); - facs = (acpi_facs_t *) current; // it will be used by fadt - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* FDAT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/pistachio/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/pistachio/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/pistachio/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -129,6 +129,28 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* FACS */ + printk(BIOS_DEBUG, "ACPI: * FACS\n"); + facs = (acpi_facs_t *) current; + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* DSDT */ + printk(BIOS_DEBUG, "ACPI: * DSDT\n"); + dsdt = (acpi_header_t *) current; + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); + /* FADT */ + printk(BIOS_DEBUG, "ACPI: * FADT\n"); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -153,28 +175,6 @@ current += ssdt->length; acpi_add_table(rsdp, ssdt); - /* FACS */ - printk(BIOS_DEBUG, "ACPI: * FACS\n"); - facs = (acpi_facs_t *) current; - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* DSDT */ - printk(BIOS_DEBUG, "ACPI: * DSDT\n"); - dsdt = (acpi_header_t *) current; - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); - /* FADT */ - printk(BIOS_DEBUG, "ACPI: * FADT\n"); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/serengeti_cheetah/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/serengeti_cheetah/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/serengeti_cheetah/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -191,6 +191,28 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* FACS */ + printk(BIOS_DEBUG, "ACPI: * FACS\n"); + facs = (acpi_facs_t *) current; + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* DSDT */ + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); + + /* FADT */ + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -268,28 +290,6 @@ } #endif - /* FACS */ - printk(BIOS_DEBUG, "ACPI: * FACS\n"); - facs = (acpi_facs_t *) current; - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* DSDT */ - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); - - /* FADT */ - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/serengeti_cheetah_fam10/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -197,6 +197,31 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* DSDT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); + + /* FACS */ // it needs 64 bit alignment + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); + facs = (acpi_facs_t *) current; + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* FADT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -289,31 +314,6 @@ } #endif - /* DSDT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n", dsdt, dsdt->length); - - /* FACS */ // it needs 64 bit alignment - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); - facs = (acpi_facs_t *) current; - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* FADT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t)); Modified: trunk/src/mainboard/amd/tilapia_fam10/acpi_tables.c ============================================================================== --- trunk/src/mainboard/amd/tilapia_fam10/acpi_tables.c Mon May 16 17:32:28 2011 (r6599) +++ trunk/src/mainboard/amd/tilapia_fam10/acpi_tables.c Fri May 20 02:06:09 2011 (r6600) @@ -127,6 +127,31 @@ acpi_write_rsdp(rsdp, rsdt, NULL); acpi_write_rsdt(rsdt); + /* DSDT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); + dsdt = (acpi_header_t *)current; // it will used by fadt + memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); + current += dsdt->length; + memcpy(dsdt, &AmlCode, dsdt->length); + printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); + + /* FACS */ // it needs 64 bit alignment + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); + facs = (acpi_facs_t *) current; // it will be used by fadt + current += sizeof(acpi_facs_t); + acpi_create_facs(facs); + + /* FADT */ + current = ( current + 0x07) & -0x08; + printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); + fadt = (acpi_fadt_t *) current; + current += sizeof(acpi_fadt_t); + + acpi_create_fadt(fadt, facs, dsdt); + acpi_add_table(rsdp, fadt); + /* * We explicitly add these tables later on: */ @@ -219,31 +244,6 @@ } #endif - /* DSDT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * DSDT at %lx\n", current); - dsdt = (acpi_header_t *)current; // it will used by fadt - memcpy(dsdt, &AmlCode, sizeof(acpi_header_t)); - current += dsdt->length; - memcpy(dsdt, &AmlCode, dsdt->length); - printk(BIOS_DEBUG, "ACPI: * DSDT @ %p Length %x\n",dsdt,dsdt->length); - - /* FACS */ // it needs 64 bit alignment - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FACS at %lx\n", current); - facs = (acpi_facs_t *) current; // it will be used by fadt - current += sizeof(acpi_facs_t); - acpi_create_facs(facs); - - /* FADT */ - current = ( current + 0x07) & -0x08; - printk(BIOS_DEBUG, "ACPI: * FADT at %lx\n", current); - fadt = (acpi_fadt_t *) current; - current += sizeof(acpi_fadt_t); - - acpi_create_fadt(fadt, facs, dsdt); - acpi_add_table(rsdp, fadt); - #if DUMP_ACPI_TABLES == 1 printk(BIOS_DEBUG, "rsdp\n"); dump_mem(rsdp, ((void *)rsdp) + sizeof(acpi_rsdp_t));

1 0

Re: [coreboot] Is there anything I can do to make coreboot better?
by shawn Bai 19 May '11

19 May '11

Dear Paul, As the beginning, the source code is needed to be download,After that, I will look into the thread you have mentioned, it's an entry point for me to go with coreboot, though I am not very familiar with ACPI.but the interest is best teacher, isn't it?I will do it step by step. Thanks for your advice. > ------------------------------ > > Message: 8 > Date: Thu, 19 May 2011 08:37:53 +0200 > From: Paul Menzel <paulepanter(a)users.sourceforge.net> > To: coreboot(a)coreboot.org > Subject: Re: [coreboot] Is there anything I can do to make coreboot > better? > Message-ID: <1305787073.4377.7.camel@mattotaupa> > Content-Type: text/plain; charset="utf-8" > > Dear Shawn, > > > Am Donnerstag, den 19.05.2011, 03:45 +0000 schrieb shawn Bai: > > Hello, guys, > > ? and girls. > > > I am very pleased to have the chance to talk with you. > > I hope I do not bother you. > > My name is Shawn Bai, and you can call me Shawn, it's OK. > > Welcome. > > > I am very interested both in the low-level in embedded system, and in > > BIOS level in desktop computer or server. > > I get to know this open source project while I browse the internet. > > > > I think it's a very good project to help me understand what happens within the system, even more. > > > > Is there anything I can do to make coreboot better? > > I have some work experience in embedded system low-level development, mainly in Board support package. > > > > Hope to hear from you soon. > > You could look into the issue raised in the other thread and try to > unify `acpi_table.c` [1]. > > Some more random notes. > > 1. To handle patches more easily? you can also use Git [2]. > 2. Please just send plain text messages to the list [3]. > 3. Another way to contact or talk to the developers is the IRC channel > [4]. > > > I am looking forward to your contributions, > > Paul > > > ? At least Sven told at the LinuxTag that handling patches with > SVN/Subversion and no commit access is a real pain. > > [1] http://www.coreboot.org/pipermail/coreboot/2011-May/065184.html > [2] http://www.coreboot.org/Git > [3] http://www.asciiribbon.org/ > [4] http://www.coreboot.org/IRC >

1 0

Fwd: Is there anything I can do to make coreboot better?
by Stefan Reinauer 19 May '11

19 May '11

this accidently went to the coreboot-announce list, resending. -------- Original Message -------- Subject: Is there anything I can do to make coreboot better? Date: Wed, 18 May 2011 14:31:53 +0000 From: shawn Bai <programassem(a)hotmail.com> To: <coreboot-announce(a)coresystems.de> Hello, guys, I am very pleased to have the chance to talk with you. I hope I do not bother you. My name is Shawn Bai, and you can call me Shawn, it's OK. I am very interested both in the low-level in embedded system, and in BIOS level in desktop computer or server. I get to know this open source project while I browse the internet. I think it's a very good project to help me understand what happens within the system, even more. Is there anything I can do to make coreboot better? I have some work experience in embedded system low-level development, mainly in Board support package. Hope to hear from you soon. Best Regards, Shawn Bai

3 2

Alternate for serial port debug messages
by Vikram Narayanan 19 May '11

19 May '11

Hi, I am using a DELL laptop. The superio used is "Found Nuvoton WPCE775x / NPCE781x (id=0x03, rev=0x06) at 0x4e". Now the thing is there are no serial ports exposed outside in my laptop. Is there any other way out to see the debug messages of coreboot.(If at all coreboot supports my motherboard, or if I am planning to try if its not there) Thanks, Vikram

6 11

Re: [coreboot] [PATCH] workaround for "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c"
by Peter Stuge 19 May '11

19 May '11

David Robinson wrote: > I can't see any compromises in applying this patch so should it be > considered it a fix rather than a workaround? No, as the problem is clearly not in coreboot. //Peter

1 0

Re: [coreboot] [PATCH] workaround for "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c"
by David Robinson 19 May '11

19 May '11

An excellent piece of debug. I spent a few days debugging this particular problem and can appreciate the work that Scott must have put in. I have tested the patch on the bimini_fam10 platform. I can't see any compromises in applying this patch so should it be considered it a fix rather than a workaround? Acked-by: David Robinson <drobinson(a)bluechiptechnology.co.uk> Blue Chip Technology David Robinson Software Development Engineer Tel : +44 (0) 1829 772000 Fax : +44 (0) 1829 772001 www.bluechiptechnology.co.uk Industrial Computers | Single Board Computers | Panel PCs | Data Acquisition | Digital Signage | Custom Design Engineer Solutions for Embedded and Industrial Computing ----- Original Message ----- From: coreboot-request(a)coreboot.org To: coreboot(a)coreboot.org Sent: Wednesday, 18 May, 2011 7:40:46 AM Subject: coreboot Digest, Vol 75, Issue 54 Send coreboot mailing list submissions to coreboot(a)coreboot.org To subscribe or unsubscribe via the World Wide Web, visit http://www.coreboot.org/mailman/listinfo/coreboot or, via email, send a message with subject or body 'help' to coreboot-request(a)coreboot.org You can reach the person managing the list at coreboot-owner(a)coreboot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of coreboot digest..." Today's Topics: 1. Re: How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed. (Peter Stuge) 2. Re: How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed. (Vikram Narayanan) 3. Re: How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed. (Vikram Narayanan) 4. Re: Kconfig vs. devicetree vs. CMOS policy for options? (Scott Duplichan) 5. [PATCH] workaround for "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c" (Scott Duplichan) ---------------------------------------------------------------------- Message: 1 Date: Wed, 18 May 2011 03:40:36 +0200 From: Peter Stuge <peter(a)stuge.se> To: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed. Message-ID: <20110518014036.31531.qmail(a)stuge.se> Content-Type: text/plain; charset=us-ascii Vikram Narayanan wrote: > Thank you. I think this can also be in Developer wiki. This might > give an insight of how much work is involved. > (or is it already there in the wiki?) Dunno..? Isn't it mostly common sense? (That development can be fast or slow, and depends on how much can be reused.) I'm not saying I am opposed to it being in the wiki, but it's also easy to spam the FAQ.. //Peter ------------------------------ Message: 2 Date: Wed, 18 May 2011 07:18:05 +0530 From: Vikram Narayanan <vikram186(a)gmail.com> To: peter <peter(a)stuge.se> Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed. Message-ID: <BANLkTinDvvQCo-3csmSddv7Gu2SsjYiE5w(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 18, 2011 at 7:10 AM, Peter Stuge <peter(a)stuge.se> wrote: > Vikram Narayanan wrote: >> Thank you. I think this can also be in Developer wiki. This might >> give an insight of how much work is involved. >> (or is it already there in the wiki?) > > Dunno..? Isn't it mostly common sense? (That development can be fast > or slow, and depends on how much can be reused.) I'm not saying I am > opposed to it being in the wiki, but it's also easy to spam the FAQ.. I agree with you. But for people who are new to the porting, this may be helpful. I don't know how many of the newbies to coreboot are aware of the fact that many things can be reused, and sometimes porting is very easy. Just a thought (to include this in wiki). - Thanks, Vikram ------------------------------ Message: 3 Date: Wed, 18 May 2011 07:08:02 +0530 From: Vikram Narayanan <vikram186(a)gmail.com> To: peter(a)stuge.se Cc: coreboot <coreboot(a)coreboot.org> Subject: Re: [coreboot] How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed. Message-ID: <BANLkTikzAE7aiy4Mmgk5C8+u6N8bqgzzBA(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 17, 2011 at 10:52 PM, Peter Stuge <peter(a)stuge.se> wrote: > Vikram Narayanan wrote: >> > It took me less then 8 hours to make my first port, and I'm not even a C >> > programmer, mine was a best case senario as there was a sibling board >> > already ported. I have also ported some where just the component where >> > supported, that didn't take to long either, probably 7-10 hours. >> > >> > Working on a board where only legacy code and docs are available I have >> > probably spend around 12 hours to get to ram init. >> > >> > I think the key to sussess is to have an easy way to reflash the bios when >> > your image failes. >> >> Seems quite inspirational to the people who wanted to port for new >> boards. >> @ Stefan: Can you please share your opinions on this? > > The time required of course depends on many factors. In general > terms, these are: > > 1. Ability to understand or learn C and programming languages in > ? general, and hardware structure. > 2. Hardware differences. > 3. How much similar code there already exists in coreboot. > 4. How readable the code is that does exist in coreboot and is > ? relevant for the project. > > In concrete terms, they are: > > 1. Programming and electronics experience, and abstract thinking > 2. How similar your mainboard is to another already supported > ? mainboard. > 3. If *any* similar mainboard is already supported by coreboot. > ? By similar I mean exact same relevant components; cpu north south > ? superio. > 4. Quality of coreboot code for cpu north south superio. > > These are just the factors to consider *when all components are > supported already*. In ideal circumstances a board port needs to take > only one hour. In reality, circumstances are never ideal and the time > needed per board grows exponentially or even steeper still with the > number of less than ideal points to consider. > > Worst case is so far 8-12 man-months for a coreboot expert. Thank you. I think this can also be in Developer wiki. This might give an insight of how much work is involved. (or is it already there in the wiki?) - Thanks, Vikram ------------------------------ Message: 4 Date: Wed, 18 May 2011 00:48:31 -0500 From: "Scott Duplichan" <scott(a)notabs.org> To: <coreboot(a)coreboot.org> Subject: Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options? Message-ID: <C5BB8B6D2558476B992F0423D71387E8@asusp67> Content-Type: text/plain; charset="us-ascii" Anders Jenbo wrote: ]You could use http://driverpacks.net/ to incorporate the AHCI driveres ]on your cd. Hello Anders, Thanks for the suggestion. I did find that site the other day. At first it looked like what I needed. But when I went to choose a download, I I could find x64 packs only for Vista/7. I use the x64 edition of XP or Server 2003. Thanks, Scott ------------------------------ Message: 5 Date: Wed, 18 May 2011 01:40:08 -0500 From: "Scott Duplichan" <scott(a)notabs.org> To: <coreboot(a)coreboot.org> Subject: [coreboot] [PATCH] workaround for "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c" Message-ID: <EA29AB5623234450BF6A861986753B34@asusp67> Content-Type: text/plain; charset="us-ascii" The attached patch works around a Windows XP or Server 2003 setup failure where an error message such as: "An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c" The value 805262864 varies, and is the physical address, in decimal, of one of the ACPI tables. Tested on Persimmon. Others abuild tested only. Signed-off-by: Scott Duplichan <scott(a)notabs.org> Detailed explanation: The error message is displayed when a 1024 dword page table array used by setupldr runs out of space. This table is used for mapping various physical addresses, such as those of ACPI tables (a separate table identity maps the lower 16MB used by setupldr code and data). Setupldr only looks at ACPI tables (FACP) to determine make and model of the system. The make and model of the system is needed when setupldr scans the good/bad bios lists contained in txtsetup.sif. The good/bad bios lists are used to bypass installation of the ACPI enabled kernel on certain systems known to have ACPI problems. The code loop that scans the lists creates a new mapping each time it reads an ACPI table, and never frees mappings. The code uses FACP OEM ID to determine the system model. The code sequentially reads tables listed in the RSDT array until the FACP is found. Each read consumes one page table entry. If more that 4 tables precede the FACP in the RSDT array, the 1024 entry page table array will run out of space before the good/bad bios list processing completes. BIOS can work around this Windows XP/Server 2003 limitation by placing the FACP early in the RSDT array. Thanks, Scott

1 0

How long will take to add coreboot support for my motherboard? Please, expert roughly estimation needed.
by Андрей Клаус 18 May '11

18 May '11

Hello everybody, I'm thinking about porting coreboot to my motherboard (epox 9NPA3I / 9NPA3J / 9NPAJ-3 / 9NPA3 Ultra Series). My chipset (CK804) and my superio (F71872F/FG) are in supported list. According to this page ( http://www.coreboot.org/Support) port "might be easy" (exactly: "If you find those in our list of Supported Chipsets and Devices<http://www.coreboot.org/Supported_Chipsets_and_Devices>a port might be easy"). I need roughly estimation for "easy" to decide is it possible for me to port coreboot or not (in time-consuming terms). So, is "easy" up to 8 hours for coreboot expert, or is it up to 40 hours for coreboot expert? Will be great if you could give me estimation for 'worst' and 'best' variant. Thank you very much, Andrey

5 8

[RFC] cheapish and free usb spi flashing device
by Stefan Tauner 18 May '11

18 May '11

hey there! (cross-posted to both mailing lists) i am currently designing a small and cheap platform to recover from coreboot and other failures easily. the reason i am writing this is to get feedback from you regarding desired features of and interest in such a device. right now my plan is the following: an avr atmegaXXu2 is connected via usb and implements the serprog protocol to let flashrom make use of it. the avr can operate down to 3.0V which would allow easy interfacing with today's spi flashes without any level shifting. to get the desired supply voltage from usb's 5V i will use a fixed 3.3V ldo voltage regulator (ld1117). apart from a few supporting parts (caps, fuse, usb line termination etc.) the only things missing are sockets for the spi chips. at the moment i am planing to include: - soic8 pads (combined for 150 and 200mil devices) and enough room for a soic8 zif adapter (like the one from http://bios-repair.co.uk) - vias for a 24 pin zif dip/dil socket (150 and 300mil spacing combined): 8 pins for dip8 flashes and 16 for soic16 flashes (those would require a soic to dip adapter). 8pin and 16pin flashes dont share pins therefore the large socket... - vias for a single row 8pin header to allow attaching probes/test clips (e.g. http://www.pomonaelectronics.com/images/large/6109.jpg) to hook up in-situ flashes. parts for this excluding the pcb would be in the 10-25$ range. depending on how many pcbs i/we would produce the whole thing would cost probably about 40$. not THAT cheap, but quite better than the dediprog stuff :) it would also be more convenient and open than the FT2232SPI based on the DLP-USB1232H (http://flashrom.org/FT2232SPI_Programmer). the willem programmers seem to be lpt only? are there any other cheap flashers i dont know? i am not sure about what to do with soic16 chips. the solution laid out above which requires an additional adapter and wastes a lot of space is awkward. should i just include soic16 pads instead? should i drop support for them altogether and let the user hook them up with clips? are they in use anywhere? my intel desktop board has pads for it, but i am not sure if there are any boards in the wild which really use them... i was also thinking about an offline mode which uses an SD-card or another flash to store/load an image for the target flash. push buttons would activate a cloning operation. this way one could clone chips easily without a pc, but i am not sure at all if thats worth it. what do you think? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 8

[commit] r6579 - in trunk/src: include/device southbridge/amd/cimx_wrapper/sb800
by repository service 18 May '11

18 May '11

Author: mjones Date: Sun May 15 23:38:08 2011 New Revision: 6579 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6579 Log: Enable AHCI mode and hide IDE controller to reduce boot time. Note: enable AHCI in seabios and apply seabios patch: http://www.mail-archive.com/seabios@seabios.org/msg00437.html Signed-off-by: Scott Duplichan <scott(a)notabs.org> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/include/device/pci_ids.h trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c Modified: trunk/src/include/device/pci_ids.h ============================================================================== --- trunk/src/include/device/pci_ids.h Sun May 15 23:26:04 2011 (r6578) +++ trunk/src/include/device/pci_ids.h Sun May 15 23:38:08 2011 (r6579) @@ -314,6 +314,7 @@ #define PCI_DEVICE_ID_ATI_SB800_LPC 0x439D #define PCI_DEVICE_ID_ATI_SB800_SATA 0x4390 +#define PCI_DEVICE_ID_ATI_SB800_SATA_AHCI 0x4391 #define PCI_DEVICE_ID_ATI_SB800_IDE 0x439C #define PCI_DEVICE_ID_ATI_SB800_HDA 0x4383 #define PCI_DEVICE_ID_ATI_SB800_PCI 0x4384 Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c ============================================================================== --- trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c Sun May 15 23:26:04 2011 (r6578) +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.c Sun May 15 23:38:08 2011 (r6579) @@ -83,7 +83,7 @@ sb_config->SATAMODE.SataMode.SataController = SATA_CONTROLLER; sb_config->SATAMODE.SataMode.SataIdeCombMdPriSecOpt = 0; //0 -IDE as primary, 1 -IDE as secondary. //TODO: set to secondary not take effect. - sb_config->SATAMODE.SataMode.SataIdeCombinedMode = 0; //IDE controlor exposed and combined mode enabled + sb_config->SATAMODE.SataMode.SataIdeCombinedMode = 1; //IDE controllor is hidden sb_config->SATAMODE.SataMode.SATARefClkSel = SATA_CLOCK_SOURCE; /* Azalia HDA */ Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h ============================================================================== --- trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h Sun May 15 23:26:04 2011 (r6578) +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/cfg.h Sun May 15 23:38:08 2011 (r6579) @@ -109,7 +109,7 @@ * NOTE: DO NOT ALLOW SATA & IDE use same mode */ #ifndef SATA_MODE - #define SATA_MODE NATIVE_IDE_MODE + #define SATA_MODE AHCI_MODE #endif /** Modified: trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c ============================================================================== --- trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c Sun May 15 23:26:04 2011 (r6578) +++ trunk/src/southbridge/amd/cimx_wrapper/sb800/late.c Sun May 15 23:38:08 2011 (r6579) @@ -138,10 +138,9 @@ static const struct pci_driver sata_driver __pci_driver = { .ops = &sata_ops, .vendor = PCI_VENDOR_ID_ATI, - .device = PCI_DEVICE_ID_ATI_SB800_SATA, //SATA IDE Mode 4390 + .device = PCI_DEVICE_ID_ATI_SB800_SATA_AHCI, }; - #if CONFIG_USBDEBUG static void usb_set_resources(struct device *dev) {

8 11

← Newer
1
...
4
5
6
7
8
9
10
...
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