[coreboot] Compaq Presario CQ50-115NR Notebook PC
Product info page: http://h10025.www1.hp.com/ewfrf/wc/document?cc=uslc=endocname=c01486798product=3752693 lspci -tvnn: $ lspci -tvnn -[:00]-+-00.0 nVidia Corporation MCP78S [GeForce 8200] Memory Controller [10de:0754] +-01.0 nVidia Corporation Device [10de:075e] +-01.1 nVidia Corporation MCP78S [GeForce 8200] SMBus [10de:0752] +-01.3 nVidia Corporation MCP78S [GeForce 8200] Co-Processor [10de:0753] +-01.4 nVidia Corporation MCP78S [GeForce 8200] Memory Controller [10de:0568] +-02.0 nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller [10de:077b] +-02.1 nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller [10de:077c] +-04.0 nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller [10de:077d] +-04.1 nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller [10de:077e] +-06.0 nVidia Corporation MCP78S [GeForce 8200] IDE [10de:0759] +-07.0 nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio [10de:0774] +-08.0-[:01]-- +-09.0 nVidia Corporation MCP78S [GeForce 8200] SATA Controller (non-AHCI mode) [10de:0ad0] +-0a.0 nVidia Corporation MCP77 Ethernet [10de:0760] +-0b.0-[:02]00.0 nVidia Corporation C77 [GeForce 8200M G] [10de:0845] +-14.0-[:07]00.0 Atheros Communications Inc. AR5001 Wireless Network Adapter [168c:001c] +-18.0 Advanced Micro Devices [AMD] Mobile K10 [Turion X2, Athlon X2, Sempron] HyperTransport Configuration [1022:1300] +-18.1 Advanced Micro Devices [AMD] Family 11h [Turion X2, Athlon X2, Sempron] Address Map [1022:1301] +-18.2 Advanced Micro Devices [AMD] Mobile K10 [Turion X2, Athlon X2, Sempron] DRAM Controller [1022:1302] +-18.3 Advanced Micro Devices [AMD] Mobile K10 [Turion X2, Athlon X2, Sempron] Miscellaneous Control [1022:1303] \-18.4 Advanced Micro Devices [AMD] Mobile K10 [Turion X2, Athlon X2, Sempron] Link Control [1022:1304] superiotool -dV: superiotool r3844 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0x, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0x, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x, id=0x Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0x, id=0x11fc Probing for ITE Super I/O (init=standard) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xfc11, rev=0x0 Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xfc11, rev=0x0 Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xfc11, rev=0x0 Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xfc11, rev=0x0 Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0x, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0x, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: sid=0xfc, srid=0xa2 Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xfc, rev=0x11 Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0x00, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at
Re: [coreboot] Compaq Presario CQ50-115NR Notebook PC
Monte Cabet wrote: -[:00]-+-00.0 nVidia Corporation MCP78S [GeForce 8200] Memory Controller [10de:0754] .. The question is if I can flash my BIOS and replace it with coreboot? Or is coreboot not mature enough to handle laptops and my mileage may vary? coreboot currently supports a few laptops based on the i945 chipset, but unfortunately not yours. NVIDIA chipsets are the least likely to ever be supported by coreboot because NVIDIA doesn't release the required documentation. flashrom may still work on your laptop, independently of coreboot. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6014 - trunk/src/northbridge/amd/gx2
Author: uwe
Date: Wed Nov 3 14:19:50 2010
New Revision: 6014
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6014
Log:
Clean up some comments and white space in gx2/northbridgeinit.c
and gx2/raminit.c.
This is Abuild and boot tested.
Signed-off-by: Nils Jacobs njaco...@hetnet.nl
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/src/northbridge/amd/gx2/northbridgeinit.c
trunk/src/northbridge/amd/gx2/raminit.c
Modified: trunk/src/northbridge/amd/gx2/northbridgeinit.c
==
--- trunk/src/northbridge/amd/gx2/northbridgeinit.c Tue Nov 2 22:24:29
2010(r6013)
+++ trunk/src/northbridge/amd/gx2/northbridgeinit.c Wed Nov 3 14:19:50
2010(r6014)
@@ -22,26 +22,25 @@
};
struct gliutable gliu0table[] = {
- {.desc_name=MSR_GLIU0_BASE1, .desc_type= BM,.hi= MSR_MC + 0x0,.lo=
0x0FFF80}, /* 0-7 to MC*/
- {.desc_name=MSR_GLIU0_BASE2, .desc_type= BM,.hi= MSR_MC +
0x0,.lo=(0x80 20) + 0x0FFFE0},/* 8-9 to Mc*/
- {.desc_name=MSR_GLIU0_SHADOW, .desc_type= SC_SHADOW,.hi= MSR_MC +
0x0,.lo= 0x03}, /* C-F split to MC and PCI (sub decode)
A-B handled by SoftVideo*/
- {.desc_name=MSR_GLIU0_SYSMEM, .desc_type= R_SYSMEM,.hi= MSR_MC,.lo=
0x0}, /* Catch and fix dynamicly.*/
- {.desc_name=MSR_GLIU0_DMM,.desc_type= BMO_DMM,.hi= MSR_MC,.lo=
0x0}, /* Catch and fix dynamicly.*/
- {.desc_name=MSR_GLIU0_SMM,.desc_type= BMO_SMM,.hi= MSR_MC,.lo=
0x0}, /* Catch and fix dynamicly.*/
+ {.desc_name=MSR_GLIU0_BASE1, .desc_type= BM,.hi= MSR_MC + 0x0,.lo=
0x0FFF80}, /* 0-7 to MC */
+ {.desc_name=MSR_GLIU0_BASE2, .desc_type= BM,.hi= MSR_MC +
0x0,.lo=(0x80 20) + 0x0FFFE0},/* 8-9 to Mc */
+ {.desc_name=MSR_GLIU0_SHADOW, .desc_type= SC_SHADOW,.hi= MSR_MC +
0x0,.lo= 0x03}, /* C-F split to MC and PCI (sub decode)
A-B handled by SoftVideo */
+ {.desc_name=MSR_GLIU0_SYSMEM, .desc_type= R_SYSMEM,.hi= MSR_MC,.lo=
0x0}, /* Catch and fix dynamicly. */
+ {.desc_name=MSR_GLIU0_DMM,.desc_type= BMO_DMM,.hi= MSR_MC,.lo=
0x0}, /* Catch and fix dynamicly. */
+ {.desc_name=MSR_GLIU0_SMM,.desc_type= BMO_SMM,.hi= MSR_MC,.lo=
0x0}, /* Catch and fix dynamicly. */
{.desc_name=GLIU0_GLD_MSR_COH,.desc_type= OTHER,.hi= 0x0,.lo= GL0_CPU},
{.desc_name=GL_END, .desc_type= GL_END,.hi= 0x0,.lo= 0x0},
};
-
struct gliutable gliu1table[] = {
- {.desc_name=MSR_GLIU1_BASE1,.desc_type= BM,.hi= MSR_GL0 + 0x0,.lo=
0x0FFF80},/* 0-7 to MC*/
- {.desc_name=MSR_GLIU1_BASE2,.desc_type= BM,.hi= MSR_GL0 + 0x0,.lo=
(0x80 20) +0x0FFFE0}, /* 8-9 to Mc*/
- {.desc_name=MSR_GLIU1_SHADOW,.desc_type= SC_SHADOW,.hi= MSR_GL0 +
0x0,.lo= 0x03}, /* C-F split to MC and PCI (sub decode)*/
- {.desc_name=MSR_GLIU1_SYSMEM,.desc_type= R_SYSMEM,.hi= MSR_GL0,.lo=
0x0},/* Catch and fix dynamicly.*/
- {.desc_name=MSR_GLIU1_DMM,.desc_type= BM_DMM,.hi= MSR_GL0,.lo= 0x0},
/* Catch and fix dynamicly.*/
- {.desc_name=MSR_GLIU1_SMM,.desc_type= BM_SMM,.hi= MSR_GL0,.lo= 0x0},
/* Catch and fix dynamicly.*/
+ {.desc_name=MSR_GLIU1_BASE1,.desc_type= BM,.hi= MSR_GL0 + 0x0,.lo=
0x0FFF80},/* 0-7 to MC */
+ {.desc_name=MSR_GLIU1_BASE2,.desc_type= BM,.hi= MSR_GL0 + 0x0,.lo=
(0x80 20) +0x0FFFE0}, /* 8-9 to Mc */
+ {.desc_name=MSR_GLIU1_SHADOW,.desc_type= SC_SHADOW,.hi= MSR_GL0 +
0x0,.lo= 0x03},/* C-F split to MC and PCI (sub decode) */
+ {.desc_name=MSR_GLIU1_SYSMEM,.desc_type= R_SYSMEM,.hi= MSR_GL0,.lo=
0x0},/* Catch and fix dynamicly. */
+ {.desc_name=MSR_GLIU1_DMM,.desc_type= BM_DMM,.hi= MSR_GL0,.lo= 0x0},
/* Catch and fix dynamicly. */
+ {.desc_name=MSR_GLIU1_SMM,.desc_type= BM_SMM,.hi= MSR_GL0,.lo= 0x0},
/* Catch and fix dynamicly. */
{.desc_name=GLIU1_GLD_MSR_COH,.desc_type= OTHER,.hi= 0x0,.lo=
GL1_GLIU0},
- {.desc_name=MSR_GLIU1_FPU_TRAP,.desc_type= SCIO,.hi= (GL1_GLCP 29)
+ 0x0,.lo= 0x033000F0},/* FooGlue FPU 0xF0*/
+ {.desc_name=MSR_GLIU1_FPU_TRAP,.desc_type= SCIO,.hi= (GL1_GLCP 29)
+ 0x0,.lo= 0x033000F0},/* FooGlue FPU 0xF0 */
{.desc_name=GL_END,.desc_type= GL_END,.hi= 0x0,.lo= 0x0},
};
@@ -54,18 +53,18 @@
struct msrinit ClockGatingDefault [] = {
{GLIU0_GLD_MSR_PM, {.hi=0x00,.lo=0x0005}},
- /* MC must stay off in SDR mode. It is turned on in
CPUBug??? lotus #77.142*/
+ /* MC must stay off in SDR mode. It is turned on in CPUBug??? lotus
#77.142 */
{MC_GLD_MSR_PM,
Re: [coreboot] [PATCH] Geode GX2 comment cleanup 1
On Tue, Nov 02, 2010 at 10:32:39PM +0100, Nils wrote: This patch cleans up some comments and white space in gx2/northbridgeinit.c and gx2/raminit.c. Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, r6014 with some further cosmetic fixes I noticed. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6015 - trunk/src/cpu/amd/model_gx2
Author: uwe
Date: Wed Nov 3 14:21:41 2010
New Revision: 6015
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6015
Log:
Clean up some more comments and white space in model_gx2/cpureginit.c.
This is Abuild and boot tested.
Signed-off-by: Nils Jacobs njaco...@hetnet.nl
Acked-by: Uwe Hermann u...@hermann-uwe.de
Modified:
trunk/src/cpu/amd/model_gx2/cpureginit.c
Modified: trunk/src/cpu/amd/model_gx2/cpureginit.c
==
--- trunk/src/cpu/amd/model_gx2/cpureginit.cWed Nov 3 14:19:50 2010
(r6014)
+++ trunk/src/cpu/amd/model_gx2/cpureginit.cWed Nov 3 14:21:41 2010
(r6015)
@@ -1,134 +1,120 @@
-/* ***/
-/* * cpuRegInit*/
-/* ***/
+/* cpuRegInit */
void cpuRegInit (void)
{
int msrnum;
msr_t msr;
- /* Turn on BTM for early debug based on setup. */
- /*if (getnvram( TOKEN_BTM_DIAG_MODE) 3) {*/
- /*
-* The following is only for diagnostics mode; do not use for OLPC
-*/
+ /* Turn on BTM for early debug based on setup. */
+ /* if (getnvram( TOKEN_BTM_DIAG_MODE) 3) { */
+ /* The following is only for diagnostics mode; do not use for OLPC */
if (0) {
- /* Set Diagnostic Mode */
+ /* Set Diagnostic Mode */
msrnum = CPU_GLD_MSR_DIAG;
msr.hi = 0;
msr.lo = DIAG_SEL1_SET | DIAG_SET0_SET;
wrmsr(msrnum, msr);
- /* Set up GLCP to grab BTM data.*/
- msrnum = 0x04C0C; /* GLCP_DBGOUT MSR*/
+ /* Set up GLCP to grab BTM data. */
+ msrnum = 0x04C0C; /* GLCP_DBGOUT MSR */
msr.hi = 0x0;
- msr.lo = 0x08; /* reset value (SCOPE_SEL = 0)
causes FIFO toshift out,*/
- wrmsr(msrnum, msr); /* exchange it to anything
else to prevent this*/
+ msr.lo = 0x08; /* reset value (SCOPE_SEL = 0)
causes FIFO toshift out, */
+ wrmsr(msrnum, msr); /* exchange it to anything else
to prevent this */
- /* ;Turn off debug clock*/
+ /* Turn off debug clock */
msrnum = 0x04C16; /* DBG_CLK_CTL*/
msr.lo = 0x00; /* No clock*/
msr.hi = 0x00;
wrmsr(msrnum, msr);
- /* ;Set debug clock to CPU*/
- msrnum = 0x04C16; /* DBG_CLK_CTL*/
- msr.lo = 0x01; /* CPU CLOCK*/
+ /* Set debug clock to CPU */
+ msrnum = 0x04C16; /* DBG_CLK_CTL */
+ msr.lo = 0x01; /* CPU CLOCK */
msr.hi = 0x00;
wrmsr(msrnum, msr);
- /* ;Set fifo ctl to BTM bits wide*/
- msrnum = 0x04C5E; /* FIFO_CTL*/
- msr.lo = 0x00388; /* Bit [25:24] are size
(11=BTM, 10 = 64 bit, 01= 32 bit, 00 = 16bit)*/
- wrmsr(msrnum, msr); /* Bit [23:21] are position (100 = CPU
downto0)*/
- /* Bit [19] sets it up
in slow data mode.*/
-
- /* ;enable fifo loading - BTM sizing will constrain*/
- /* ; only valid BTM packets to load - this action should always
be on*/
-
- msrnum = 0x04C6F; /* GLCP ACTION7 - load fifo*/
- msr.lo = 0x0F000; /*Any nibble all 1's will
always trigger*/
- msr.hi = 0x0; /* */
- wrmsr(msrnum, msr);
-
- /* ;start storing diag data in the fifo*/
- msrnum = 0x04C5F; /* DIAG CTL*/
- msr.lo = 0x08000; /* enable actions*/
+ /* Set fifo ctl to BTM bits wide */
+ msrnum = 0x04C5E; /* FIFO_CTL */
+ msr.lo = 0x00388; /* Bit [25:24] are size
(11=BTM, 10 = 64 bit, 01= 32 bit, 00 = 16bit) */
+ wrmsr(msrnum, msr); /* Bit [23:21] are position
(100 = CPU downto0) */
+ /* Bit [19] sets it up in slow
data mode. */
+
+ /* enable fifo loading - BTM sizing will constrain */
+ /* only valid BTM packets to load - this action should always
be on */
+ msrnum = 0x04C6F; /* GLCP ACTION7 - load fifo */
+ msr.lo = 0x0F000; /* Any nibble all 1's will
always trigger */
msr.hi = 0x0;
wrmsr(msrnum, msr);
- /* Set up delay on data lines, so that the hold
Re: [coreboot] [PATCH] Geode GX2 comment cleanup 2
On Tue, Nov 02, 2010 at 10:32:59PM +0100, Nils wrote: This patch cleans up some more comments and white space in model_gx2/cpureginit.c . Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, r6015. Minor request, please drop the This patch ... from the patch descriptions, just say directly what it does (as we usually use the description as commit message). Clean up stuff looks better than This patch cleans up stuff in svn logs. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6016 - trunk/src/northbridge/amd/gx2
Author: uwe Date: Wed Nov 3 14:24:29 2010 New Revision: 6016 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6016 Log: Remove some unused code from gx2/raminit.c. This is Abuild and boot tested. Signed-off-by: Nils Jacobs njaco...@hetnet.nl Acked-by: Uwe Hermann u...@hermann-uwe.de Modified: trunk/src/northbridge/amd/gx2/raminit.c Modified: trunk/src/northbridge/amd/gx2/raminit.c == --- trunk/src/northbridge/amd/gx2/raminit.c Wed Nov 3 14:21:41 2010 (r6015) +++ trunk/src/northbridge/amd/gx2/raminit.c Wed Nov 3 14:24:29 2010 (r6016) @@ -460,12 +460,6 @@ msr.lo = ~0xC0; msr.lo |= 0x0; /* set refresh to 4SDRAM clocks */ wrmsr(msrnum, msr); - - /* Memory Interleave: Set HOI here otherwise default is LOI */ - /* msrnum = MC_CF8F_DATA; - msr = rdmsr(msrnum); - msr.hi |= CF8F_UPPER_HOI_LOI_SET; - wrmsr(msrnum, msr); */ } static void sdram_set_spd_registers(const struct mem_controller *ctrl) -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Remove unused code from Geode GX2
On Tue, Nov 02, 2010 at 10:33:53PM +0100, Nils wrote: This patch removes some unused code from gx2/raminit.c . Signed-off-by: Nils Jacobs njaco...@hetnet.nl Thanks, r6016. Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] simplify vt8237r_early_smbus.c (was: Re: [PATCH 3/7] ASUS M2V support (v2): simplify vt8237r_early_smbus.c (unchanged))
Rudolf Marek wrote:
On 29.10.2010 13:59, Tobias Diedrich wrote:
Instead of duplicating the pci_locate_device calls multiple times,
add a get_vt8237_lpc() function.
Yeah nice idea! Can I get separate patch for that? In the meanwhile do we
need to call the enablefidvid for A ? I think we dont scritly need
that. Maybe we can make it part of 2/7 and leave this just for the grand
get_vt8237_lpc() function? (and I can apply that before 2/7 so you don't
need to re-do the stuff)
Here you go:
Instead of duplicating the pci_locate_device calls multiple times,
add a get_vt8237_lpc() function.
The devid variable introduced to vt8237_sb_enable_fid_vid() in hunk 3
will come in handy in the patch adding vt8237a support.
I think it also makes the logic a bit more clear.
The other option would be to not use get_vt8237_lpc() in
vt8237_sb_enable_fid_vid() and leave that bit to the vt8237a support
patch.
Signed-off-by: Tobias Diedrich ranma+coreb...@tdiedrich.de
---
Index: src/southbridge/via/vt8237r/vt8237r_early_smbus.c
===
--- src/southbridge/via/vt8237r/vt8237r_early_smbus.c.orig 2010-11-03
14:54:54.0 +0100
+++ src/southbridge/via/vt8237r/vt8237r_early_smbus.c 2010-11-03
15:00:34.0 +0100
@@ -134,6 +134,21 @@
#define PSONREADY_TIMEOUT 0x7fff
+static device_t get_vt8237_lpc(void)
+{
+ device_t dev;
+
+ /* Power management controller */
+ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_VT8237R_LPC), 0);
+ if (dev != PCI_DEV_INVALID)
+ return dev;
+
+ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_VT8237S_LPC), 0);
+ return dev;
+}
+
/**
* Enable the SMBus on VT8237R-based systems.
*/
@@ -143,15 +158,9 @@
int loops;
/* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237R_LPC), 0);
- if (dev == PCI_DEV_INVALID) {
- /* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237S_LPC), 0);
- if (dev == PCI_DEV_INVALID)
- die(Power management controller not found\n);
- }
+ dev = get_vt8237_lpc();
+ if (dev == PCI_DEV_INVALID)
+ die(Power management controller not found\n);
/* Make sure the RTC power well is up before touching smbus. */
loops = 0;
@@ -235,17 +244,15 @@
void vt8237_sb_enable_fid_vid(void)
{
device_t dev, devctl;
+ u16 devid;
/* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237R_LPC), 0);
- if (dev == PCI_DEV_INVALID) {
- /* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237S_LPC), 0);
- if (dev == PCI_DEV_INVALID)
- return;
+ dev = get_vt8237_lpc();
+ if (dev == PCI_DEV_INVALID)
+ return;
+ devid = pci_read_config16(dev, PCI_DEVICE_ID);
+ if (devid == PCI_DEVICE_ID_VIA_VT8237S_LPC) {
devctl = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_VT8237_VLINK), 0);
@@ -292,15 +292,9 @@
device_t dev;
/* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237R_LPC), 0);
- if (dev == PCI_DEV_INVALID) {
- /* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237S_LPC), 0);
- if (dev == PCI_DEV_INVALID)
- return;
- }
+ dev = get_vt8237_lpc();
+ if (dev == PCI_DEV_INVALID)
+ return;
/* ROM decode last 1MB FFC0 - . */
pci_write_config8(dev, 0x41, 0x7f);
@@ -316,15 +310,9 @@
print_debug(IN TEST WAKEUP\n);
/* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237R_LPC), 0);
- if (dev == PCI_DEV_INVALID) {
- /* Power management controller */
- dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
- PCI_DEVICE_ID_VIA_VT8237S_LPC), 0);
- if (dev == PCI_DEV_INVALID)
- die(Power management controller not found\n);
- }
+ dev = get_vt8237_lpc();
+ if (dev ==
Re: [coreboot] [PATCH] don't print too early on mcp55-based boards
On Tue, Nov 02, 2010 at 11:20:43PM +0100, Uwe Hermann wrote: I don't object to the patch, and we should probably fix this in all other southbridges, I think the same problem applies there. But: the die() call itself also does a printk(), so that'll still hang if the error path is chosen (at that point it probably doesn't matter much, though, as we die anyway). Right, I think it does not matter. If the die happens when printk is already functional, great, if not it will hang there which is fine. I also agree that die() should have a POST code, preferrably something easy to remember. It already has a commented-out //post_code(0xff);. Not sure why it's disabled, but I think it should be something other than 0xff, that's a bit too special for my taste. We have 0xee: Not supposed to get here as per documentation/POSTCODES, so maybe we can use 0xdd (d as in die), if that's not already used elsewhere. So, thinking about this a little more, I'm not sure adding a post code to 'die' is a good idea. The problem with doing that is that it would clobber any previous post codes, which might be a better indicator for what's going wrong. Perhaps a good way to deal with fatal runtime error conditions would be a) set a unique post code b) call die in the assumption that die does not clobber the post code. What do you think? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 7/7] ASUS M2V support (v2): Add m2v mainboard directory and files
Rudolf Marek wrote:
On 29.10.2010 14:14, Tobias Diedrich wrote:
This adds the m2v directory to src/mainboards/asus and adjusts the Kconfig.
Note:
I added pci irq routing setup based on pirq tables:
pci_fixup_irqs() in irq_tables.c
I didn't see any existing functionality that will just take the pirq
information and use that to setup pci interrupts.
For example, in src/southbridge/via/vt8237r/vt8237r_lpc.c there is
some epia specific setup, which may really belong into the
corresponding mainboard directory...
Hmm the legacy PIC routing may not work. In linux it could. I never tested
that.
I currently working on cleaning up the mainboard part, but I tested
legacy pic routing (which is why I added this function), acpi w/o
apic, acpi with apic and mptables with apic, each in both XP and Linux.
+/* Write SB IOAPIC. */
+current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,
+VT8237R_APIC_ID, IO_APIC_ADDR, 0);
+
+/* Write NB IOAPIC. */
+current += acpi_create_madt_ioapic((acpi_madt_ioapic_t *) current,
+K8T890_APIC_ID, K8T890_APIC_BASE, gsi_base);
I never used the VIA system on multicore CPU, dunno what to do if we have
in fact more cpus... The IDs should be shifted then.
The IDs are currently hardcoded:
src/southbridge/via/k8t890/k8t890.h:
#define K8T890_APIC_ID 0x3
#define K8T890_APIC_BASE0xfecc
src/southbridge/via/vt8237r/vt8237r.h
#define VT8237R_APIC_ID 0x2
Which is good for up to dual-core, should be shifted up for
quad-core... Maybe we should change this to 0x10 and 0x11? (up to 16 cores)
Not sure how many bits are available for the ID by default, but I
saw that there is an enable bit for extended ID numbers somewhere.
+++ src/mainboard/asus/m2v/dsdt.asl 2010-10-29 14:07:37.0 +0200
@@ -0,0 +1,967 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2004 Nick Barkernick.bark...@btinternet.com
+ * Copyright (C) 2007 Rudolf Marekr.ma...@assembler.cz
+ * Copyright (C) 2010 Tobias Diedrichranma+coreb...@tdiedrich.de
Where you have taken parts of it? Some parts feel like AMD 7xx code?
Maybe we miss copyright here?
Portions (e.g. Remember the OS' IRQ routing choice are from
src/mainboard/ibase/mb899/acpi/), I'll add Copyright (C) 2007-2009
coresystems GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/*
+ * ISA portions taken from QEMU acpi-dsdt.dsl.
+ */
+
+DefinitionBlock (DSDT.aml, DSDT, 2, CORE , COREBOOT, 1)
+{
+/* Data to be patched by the BIOS during POST */
+/* FIXME the patching is not done yet! */
+/* Memory related values */
+Name(LOMH, 0x0) /* Start of unused memory in C-E range */
+Name(PBAD, 0x0) /* Address of BIOS area (If TOM2 != 0, Addr 16) */
+Name(PBLN, 0x0) /* Length of BIOS area */
We dont do patching we do apcigen stuff instead into SSDT.
That's copied from gigabyte/ma78gm/dsdt.asl, I'll remove it, it
isn't used anyway. As I already said elsewhere, I haven't cleaned
up the mainboard bits yet, especially the acpi stuff.
+
+Name(PCBA, 0xE000) /* Base address of PCIe config space */
This cannot be hardcoded.
Ok, then I'll add it to the SSDT generation code and use an
external.
+Name(HPBA, 0xFED0) /* Base address of HPET table */
+
+/* global variables */
+Name(APIC, 0) // 0=8259, 1=IOAPIC
+Name(LINX, 0)
+Name(OSYS, 0x)
+
+/* very generic stuff */
+
+/* Port 80 POST */
+
+OperationRegion (POST, SystemIO, 0x80, 1)
+Field (POST, ByteAcc, Lock, Preserve)
+{
+DBG0, 8
+}
+
+Method (DEBG, 1, NotSerialized)
+{
+Store (Arg0, DBG0)
+}
+
I dont think you need this. My philosophy for ACPI code is: Put there
only what is needed even no extra bit more.
I thought the POST port might come in handy for debugging, but haven't used it
so far.
+/* _PR CPU0 is dynamically supplied by SSDT */
+
+/* For now only define 2 power states:
+ * - S0 which is fully on
+ * - S5 which is soft off
+ * Any others would involve declaring the wake up methods.
+ *
+ * Package contents:
+ * ofs len desc
+ * 0 1 Value for PM1a_CNT.SLP_TYP register
[coreboot] F71889 Super I/O patch
Hello, I looked over the F71889 Fintek datasheet, and its very similar to the F71863FG I noticed. I used sed to replace some of the names around and such. I haven't tested it, nor will I, since I have little to no experience with flashing devices, and have no back-up (can't recover) and I do have a stub (that most likely wont work) for the MSI MS785GT-E63 board, and it compiled fine and all, using the F71889 code, I mainly just changed the romstage.c file around to make it fit, while still basing the code off the other 785 boards. If anybody wants to test the F71889 patch, feel free. Also I wasn't sure to keep the same name in the other Fintek chips or not, so I changed the name to mine, and the year. I apologize if that was incorrect, and will be more than willing to keep the original GNU header. Some indentation was changed when using svn diff to generate the patch. -Alec Ari neotheu...@ymail.com f71889.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised)
Hi Scott, I am not totally convinced that all changes are a net win. On 03.11.2010 05:29, Scott Duplichan wrote: (Re-submitting with correction to GFX debug bar setup procedure needed for use with AMD family 0Fh processor). This patch solves crashes and BSODs that occur when booting Win7 with AMD RS780 uma graphics. Tested with frame buffer sizes 64m through 1GB by running dxdiag and Windows media player at 1600x1200 true color. Additional changes needed to boot Win7 on Mahogany_fam10 will follow. -- Enable and program the debug bar as required by the ATI graphics driver. First, make the debug bar writable and allow resource allocation code to program it. Once programmed, enable its operation. Good. -- Disable the family 10h processor mmconf while the RS780 mmconf is in use. I thought the family 10h processors need their own MMCONF for some configuration accesses. If this disable happens after all such config writes are done, I'm OK with it. -- Make strap programming more closely follow the reference BIOS. Good. -- Disable PCIe bar 3 after using it. This one is something I have reservations about. Isn't PCIe BAR 3 the one via which MMCONF accesses are done? How is MMCONF going to work after that? -- UMA size is no longer hardcoded. Nice. -- Disable write combining for all steppings to eliminate stability problem. This may have a performance impact, right? Do you know if any steppings with stable write combining exist? -- Correct task file data. -- Improve the accuracy of the Atom table that passes information to the driver. Yes, that's definitely needed. Signed-off-by: Scott Duplichan sc...@notabs.org I think the patch looks good, but I'd like a few answers before I ack it. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 2/7] ASUS M2V support (v2): VT8237A LPC device id (unchanged)
Rudolf Marek wrote:
Hi,
I think following is not true. The VT8237A has something else at 0x50, so
vt8237_sb_enable_fid_vid should not be neccessary to call. Do you call it
or not? If not then we either need to fix it for the old location 0x11
iirc or not to put there any test for A version.
+static const struct device_operations vt8237r_lpc_ops_a = {
+.read_resources = vt8237r_read_resources,
+.set_resources = pci_dev_set_resources,
+.enable_resources = pci_dev_enable_resources,
+.init = vt8237r_init,
+.scan_bus = scan_static_bus,
+};
+
I think you dont need this for now, if you use r init version you can
cange it directly:
+static const struct pci_driver lpc_driver_a __pci_driver = {
+.ops=vt8237r_lpc_ops_a,
Updated patch:
This adds the VT8237A LPC device id and corresponding pci_locate_device
calls in vt8237r_early_smbus.c plus the pci_driver struct in
vt8237r_lpc.c
Signed-off-by: Tobias Diedrich ranma+coreb...@tdiedrich.de
---
Index: src/southbridge/via/vt8237r/vt8237r_early_smbus.c
===
--- src/southbridge/via/vt8237r/vt8237r_early_smbus.c.orig 2010-11-03
15:15:02.0 +0100
+++ src/southbridge/via/vt8237r/vt8237r_early_smbus.c 2010-11-03
15:15:25.0 +0100
@@ -146,6 +146,11 @@
dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_VT8237S_LPC), 0);
+ if (dev != PCI_DEV_INVALID)
+ return dev;
+
+ dev = pci_locate_device(PCI_ID(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_VT8237A_LPC), 0);
return dev;
}
Index: src/southbridge/via/vt8237r/vt8237r_lpc.c
===
--- src/southbridge/via/vt8237r/vt8237r_lpc.c.orig 2010-11-03
14:54:54.0 +0100
+++ src/southbridge/via/vt8237r/vt8237r_lpc.c 2010-11-03 15:16:35.0
+0100
@@ -543,6 +543,12 @@
.device = PCI_DEVICE_ID_VIA_VT8237R_LPC,
};
+static const struct pci_driver lpc_driver_a __pci_driver = {
+ .ops= vt8237r_lpc_ops_r,
+ .vendor = PCI_VENDOR_ID_VIA,
+ .device = PCI_DEVICE_ID_VIA_VT8237A_LPC,
+};
+
static const struct pci_driver lpc_driver_s __pci_driver = {
.ops= vt8237r_lpc_ops_s,
.vendor = PCI_VENDOR_ID_VIA,
Index: src/include/device/pci_ids.h
===
--- src/include/device/pci_ids.h.orig 2010-11-03 14:54:54.0 +0100
+++ src/include/device/pci_ids.h2010-11-03 15:14:49.0 +0100
@@ -1226,6 +1226,7 @@
#define PCI_DEVICE_ID_VIA_K8T890CE_BR 0xb188
#define PCI_DEVICE_ID_VIA_VT6420_SATA 0x3149
#define PCI_DEVICE_ID_VIA_VT8237R_LPC 0x3227
+#define PCI_DEVICE_ID_VIA_VT8237A_LPC 0x3337
#define PCI_DEVICE_ID_VIA_VT8237S_LPC 0x3372
#define PCI_DEVICE_ID_VIA_VT8237_SATA 0x5372
#define PCI_DEVICE_ID_VIA_VT8237_VLINK 0x287e
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 4/7] ASUS M2V support (v2): VT8237A specific initialization
Rudolf Marek wrote:
+if (!devfun7)
+return;
+
+/*
+ * This init code is valid only for the VT8237A! For different
+ * sounthbridges (e.g. VT8237S, VT8237R (without plus R)
typo :) maybe was just copied? Did you get the values from orig bios? Or
just copied? For what vlink mode it is 8x? I got some VIA recommended
values but they are bit different 0xb5 is 0x88.
+/* FIXME: Intel needs more bit set for C2/C3. */
+
+/*
+ * Allow SLP# signal to assert LDTSTOP_L.
+ * Will work for C3 and for FID/VID change. FIXME FIXME, pre rev A2.
What is fixme fixme pre revA2?
+ */
+outb(0x1, VT8237R_ACPI_IO_BASE + 0x11);
+
+dump_south(dev);
+}
+
static void vt8237s_init(struct device *dev)
{
u32 tmp;
@@ -541,7 +584,7 @@
.read_resources = vt8237r_read_resources,
.set_resources = pci_dev_set_resources,
.enable_resources = pci_dev_enable_resources,
-.init = vt8237r_init,
+.init = vt8237a_init,
.scan_bus = scan_static_bus,
};
Otherwise fine.
Updated patch:
This adds VT8237A specific VLINK/LPC init functions in vt8237_ctrl.c,
vt8237r_lpc.c and vt8237r_early_smbus.c
I ran some tests and apparently both the
| /* So the chip knows we are on AMD. */
| pci_write_config8(devctl, 0x7c, 0x7f);
and
| /*
|* Allow SLP# signal to assert LDTSTOP_L.
|* Will work for C3 and for FID/VID change.
|*/
| outb(0x1, VT8237R_ACPI_IO_BASE + 0x11);
in vt8237r_early_smbus.c are needed on VT8237A, otherwise I get a (non-fatal)
fid/vid change error on boot.
While vt8237a_vlink_init() in vt8237_ctrl.c is a modified vt8237r_vlink_init(),
vt8237a_init() in vt8237r_lpc.c is a modified vt8237s_init().
Signed-off-by: Tobias Diedrich ranma+coreb...@tdiedrich.de
---
Index: src/southbridge/via/vt8237r/vt8237_ctrl.c
===
--- src/southbridge/via/vt8237r/vt8237_ctrl.c.orig 2010-11-03
15:23:19.0 +0100
+++ src/southbridge/via/vt8237r/vt8237_ctrl.c 2010-11-03 15:37:25.0
+0100
@@ -168,6 +168,75 @@
}
+static void vt8237a_vlink_init(struct device *dev)
+{
+ u8 reg;
+ device_t devfun7;
+
+ devfun7 = dev_find_device(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_K8T890CE_7, 0);
+ if (!devfun7)
+ devfun7 = dev_find_device(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_K8M890CE_7, 0);
+ if (!devfun7)
+ devfun7 = dev_find_device(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_K8T890CF_7, 0);
+ /* No pairing NB was found. */
+ if (!devfun7)
+ return;
+
+ /*
+* This init code is valid only for the VT8237A! For different
+* sounthbridges (e.g. VT8237S, VT8237R and VT8251) a different
+* init code is required.
+*
+* FIXME: This is based on vt8237r_vlink_init() in
+*k8t890/k8t890_ctrl.c and modified to fit what the AMI
+*BIOS on my M2V wrote to these registers (by looking
+*at lspci -nxxx output).
+*Works for me.
+*/
+
+ /* disable auto disconnect */
+ reg = pci_read_config8(devfun7, 0x42);
+ reg = ~0x4;
+ pci_write_config8(devfun7, 0x42, reg);
+
+ /* NB part setup */
+ pci_write_config8(devfun7, 0xb5, 0x88);
+ pci_write_config8(devfun7, 0xb6, 0x88);
+ pci_write_config8(devfun7, 0xb7, 0x61);
+
+ reg = pci_read_config8(devfun7, 0xb4);
+ reg |= 0x11;
+ pci_write_config8(devfun7, 0xb4, reg);
+
+ pci_write_config8(devfun7, 0xb0, 0x6);
+ pci_write_config8(devfun7, 0xb1, 0x1);
+
+ /* SB part setup */
+ pci_write_config8(dev, 0xb7, 0x50);
+ pci_write_config8(dev, 0xb9, 0x88);
+ pci_write_config8(dev, 0xba, 0x8a);
+ pci_write_config8(dev, 0xbb, 0x88);
+
+ reg = pci_read_config8(dev, 0xbd);
+ reg |= 0x3;
+ reg = ~0x4;
+ pci_write_config8(dev, 0xbd, reg);
+
+ reg = pci_read_config8(dev, 0xbc);
+ reg = ~0x7;
+ pci_write_config8(dev, 0xbc, reg);
+
+ pci_write_config8(dev, 0x48, 0x23);
+
+ /* enable auto disconnect, for STPGNT and HALT */
+ reg = pci_read_config8(devfun7, 0x42);
+ reg |= 0x7;
+ pci_write_config8(devfun7, 0x42, reg);
+}
+
static void ctrl_enable(struct device *dev)
{
/* Enable the 0:13 and 0:13.1. */
@@ -193,6 +262,12 @@
vt8237s_vlink_init(dev);
}
+ devsb = dev_find_device(PCI_VENDOR_ID_VIA,
+ PCI_DEVICE_ID_VIA_VT8237A_LPC, 0);
+ if (devsb) {
+ vt8237a_vlink_init(dev);
+ }
+
/* Configure PCI1 and copy mirror registers from D0F3. */
Re: [coreboot] [PATCH 6/7] ASUS M2V support (v2): Comments (unchanged)
Rudolf Marek wrote:
-/* ROM memory cycles go to LPC. */
+/* Only ROM memory cycles go to LPC. */
I think it should be,
+ /* Only memory ROM cycles go to LPC. */
Because this bit is telling if all memory cycles should go to LPC or just
those from ROM range. Please try to rephase that.
Updated patch:
Comment changes, add pointer to PCIe bridge documentation.
Signed-off-by: Tobias Diedrich ranma+coreb...@tdiedrich.de
---
Index: src/southbridge/via/k8t890/k8t890_ctrl.c
===
--- src/southbridge/via/k8t890/k8t890_ctrl.c.orig 2010-11-03
14:53:07.0 +0100
+++ src/southbridge/via/k8t890/k8t890_ctrl.c2010-11-03 15:51:23.0
+0100
@@ -154,7 +154,11 @@
pci_write_config8(dev, 0x47, 0x30);
- /* VT8237R specific configuration other SB are done in their own
directories */
+ /*
+* VT8237R specific configuration,
+* other SB are done in their own directories:
+* VT8237A and VT8237S are handled in vt8237_ctrl.c
+*/
device_t devsb = dev_find_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_VT8237R_LPC, 0);
Index: src/southbridge/via/vt8237r/vt8237r_lpc.c
===
--- src/southbridge/via/vt8237r/vt8237r_lpc.c.orig 2010-11-03
15:50:51.0 +0100
+++ src/southbridge/via/vt8237r/vt8237r_lpc.c 2010-11-03 16:02:37.0
+0100
@@ -457,7 +457,18 @@
/* I/O recovery time, default IDE routing */
pci_write_config8(dev, 0x4c, 0x04);
- /* ROM memory cycles go to LPC. */
+ /*
+* Bit | Meaning
+* 7 | 1: Only ROM memory cycles go to LPC instead of all memory
+* |cycles.
+* 6 | 0: Internal ISA cycles do not arbitrate with secondary IDE
+* 5 | 0: Disable LPC RTC
+* 4 | 0: Disable LPC Keyboard
+* 3 | 0: Disable Port 0x62/0x66 to LPC
+* 2 | 0: Disable Port 0x62/0x66 MCCS# chipselect decoding
+* 1 | 0: Disable A20M# signal (signal not asserted)
+* 0 | 0: Disable NMI on PCI parity error
+*/
pci_write_config8(dev, 0x59, 0x80);
/*
@@ -479,7 +490,18 @@
/* I/O recovery time, default IDE routing */
pci_write_config8(dev, 0x4c, 0x44);
- /* ROM memory cycles go to LPC. */
+ /*
+* Bit | Meaning
+* 7 | 1: Only ROM memory cycles go to LPC instead of all memory
+* |cycles.
+* 6 | 0: Internal ISA cycles do not arbitrate with secondary IDE
+* 5 | 0: Disable LPC RTC
+* 4 | 0: Disable LPC Keyboard
+* 3 | 0: Disable Port 0x62/0x66 to LPC
+* 2 | 0: Disable Port 0x62/0x66 MCCS# chipselect decoding
+* 1 | 0: Disable A20M# signal (signal not asserted)
+* 0 | 0: Disable NMI on PCI parity error
+*/
pci_write_config8(dev, 0x59, 0x80);
/*
Index: src/southbridge/via/k8t890/k8t890_pcie.c
===
--- src/southbridge/via/k8t890/k8t890_pcie.c.orig 2010-11-03
14:53:07.0 +0100
+++ src/southbridge/via/k8t890/k8t890_pcie.c2010-11-03 15:51:23.0
+0100
@@ -24,6 +24,12 @@
#include device/pci_ids.h
#include k8t890.h
+/*
+ * Note:
+ * The pcie bridges are similar to the VX800 ones documented at
+ * http://linux.via.com.tw/
+ */
+
static void peg_init(struct device *dev)
{
u8 reg;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 7/7] ASUS M2V support (v2): Add m2v mainboard directory and files
Tobias Diedrich wrote: + /* + * Northbridge pcie bridge 3.3 is not connected to anything, hide it. + */ + tmp = pci_cf8_conf1.read8(NULL, 0, PCI_DEVFN(0x0, 5), 0xf0); + tmp= ~0x10; /* hide pcie bridge 0:3.3 */ + tmp= ~0x40; /* hide scratch register function 0:0.6 */ + pci_cf8_conf1.write8(NULL, 0, PCI_DEVFN(0x0, 5), 0xf0, tmp); + /* Enable southbridge bridges 13.0 and 13.1 */ + pci_cf8_conf1.write8(NULL, 0, PCI_DEVFN(0x11, 7), 0X4F, 0x43); Hmm this most likely shoudl be done with the help of devicetree.cb I don't see how this can be done with devicetree.cb. device pci 3.3 off end I think all ranges that have mapped devices and are unavailable for PCI bars should be marked as reserved in E820 for correctness. Should probably be done in the chipset code and not in the mainboard code though. I agree - and that would be wonderful! //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] F71889 Super I/O patch
Signed-off-by: Alec Ari neotheu...@ymail.com --- On Wed, 11/3/10, Neo The User neotheu...@ymail.com wrote: From: Neo The User neotheu...@ymail.com Subject: F71889 Super I/O patch To: coreboot@coreboot.org Date: Wednesday, November 3, 2010, 5:55 PM Hello, I looked over the F71889 Fintek datasheet, and its very similar to the F71863FG I noticed. I used sed to replace some of the names around and such. I haven't tested it, nor will I, since I have little to no experience with flashing devices, and have no back-up (can't recover) and I do have a stub (that most likely wont work) for the MSI MS785GT-E63 board, and it compiled fine and all, using the F71889 code, I mainly just changed the romstage.c file around to make it fit, while still basing the code off the other 785 boards. If anybody wants to test the F71889 patch, feel free. Also I wasn't sure to keep the same name in the other Fintek chips or not, so I changed the name to mine, and the year. I apologize if that was incorrect, and will be more than willing to keep the original GNU header. Some indentation was changed when using svn diff to generate the patch. -Alec Ari neotheu...@ymail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH 7/7] ASUS M2V support (v2): Add m2v mainboard directory and files
Peter Stuge wrote: Tobias Diedrich wrote: +/* + * Northbridge pcie bridge 3.3 is not connected to anything, hide it. + */ +tmp = pci_cf8_conf1.read8(NULL, 0, PCI_DEVFN(0x0, 5), 0xf0); +tmp= ~0x10; /* hide pcie bridge 0:3.3 */ +tmp= ~0x40; /* hide scratch register function 0:0.6 */ +pci_cf8_conf1.write8(NULL, 0, PCI_DEVFN(0x0, 5), 0xf0, tmp); +/* Enable southbridge bridges 13.0 and 13.1 */ +pci_cf8_conf1.write8(NULL, 0, PCI_DEVFN(0x11, 7), 0X4F, 0x43); Hmm this most likely shoudl be done with the help of devicetree.cb I don't see how this can be done with devicetree.cb. device pci 3.3 off end That does something different though I think. I.e. the bridge is still visible as a device, even if we leave it unconfigured. The code above completely removes the device so it is no longer visible at all. Since we don't use the scratch register function 0:0.6 and the 4th pcie bridge 0:3.3 is not physically wired to anything I thought it would be neat to just disable those two completely. I think all ranges that have mapped devices and are unavailable for PCI bars should be marked as reserved in E820 for correctness. Should probably be done in the chipset code and not in the mainboard code though. I agree - and that would be wonderful! I'll look into it. -- Tobias PGP: http://8ef7ddba.uguu.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Geode GX2 comment cleanup 1
Op woensdag 3 november 2010 14:20:31 schreef u: Thanks, r6014 with some further cosmetic fixes I noticed. Uwe. Thanks for the fast review and commit. Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] EPIA halting after vt8601 init
Hello, please advise on EPIA 800 board hanging after northbridge initialisation. I checked against chipset datasheet and working AWARD dump - the northbridge SDRAM configuration registers are correctly set. There are no errors in memory test, I can induce errors in memory test for example with wrongly configured paging registers. I have tested with five different memory modules (single/double sided, differing speeds, latencys). I did found an old thread (by Al Hooton) with similar problem, that was resolved with correct CAS latency setting, does not help in this case. Outcome does not differ with/without payload(s) and the hardware passes all tests with AWARD I can throw at it. Is this rom structure reasonable (missing fallback/romstage?): CBFSPRINT coreboot.rom coreboot.rom: 256 kB, bootblocksize 65536, romsize 262144, offset 0x0 Alignment: 64 bytes Name Offset Type Size fallback/coreboot_ram 0x0 stage 47306 fallback/payload 0xb940 payload 17021 pci1023,8500.rom0xfc00 optionrom49152 (empty) 0x1bc40null 82808 What I get out from console with SPEW: coreboot-4.0-r6016M Wed Nov 3 21:17:24 EET 2010 starting... 87 is the comm register SMBus controller enabled vt8601 init starting is the north 1106 0601 0120d4 is the computed timing NOP PRECHARGE DUMMY READS CBR MRS NORMAL set ref. rate enable multi-page open Slot 00 is SDRAM 2000 bytes 000e is the MA type Slot 01 is empty Slot 02 is empty Slot 03 is empty vt8601 done northbridge dump 00:06 11 01 06 06 00 90 22 05 00 00 06 00 00 00 00 10:08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50:ac 08 80 00 00 00 40 40 e0 00 40 40 40 40 40 40 60:3f 00 00 31 e6 95 95 00 52 3c 86 0d 08 7f 00 00 70:00 00 00 00 00 00 00 00 01 f0 00 00 00 00 00 00 80:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:02 00 20 00 03 02 00 07 00 00 00 00 08 02 00 00 b0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00 memory tests Testing DRAM : -000a DRAM fill: -000a 000a DRAM filled DRAM verify: -000a 000a DRAM range verified. Done. Testing DRAM : 0010-0100 DRAM fill: 0010-0100 0100 DRAM filled DRAM verify: 0010-0100 0100 DRAM range verified. Done. Loading stage image. Check CBFS header at hangs here With lower loglevel: coreboot-4.0-r6016M Wed Nov 3 21:30:53 EET 2010 starting... vt8601 init starting Slot 00 is SDRAM 2000 bytes Slot 01 is empty Slot 02 is empty Slot 03 is empty vt8601 done Stage: loading fallback/coreboot_ram @ 0x hangs here Regards, Toomas Pruuden -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Geode GX2 comment cleanup 2
Hi Uwe, Op woensdag 3 november 2010 14:23:36 schreef u: Thanks, r6015 Thanks for the fast review and commit. Clean up stuff looks better than This patch cleans up stuff in svn logs. OK will do better next time. Thanks, Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] EPIA halting after vt8601 init
Is this rom structure reasonable (missing fallback/romstage?): It's fine. The romstage (boot block) isn't part of CBFS. Loading stage image. Check CBFS header at hangs here Normally a hang here means that the whole ROM isn't mapped, so trying to read from the top of the ROM hangs, even though the bootblock accesses work fine. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Remove unused code from Geode GX2
Uwe wrote, Op woensdag 3 november 2010 14:24:47 schreef u: Thanks, r6016. Thanks for the fast review and commit. Nils. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] via k8t890/vt8237: mark mmconf, apic and bios resources as reserved
Ranges unavailable for PCI BARs should be marked as reserved in the E820 memory map, in case the OS wants to change the BARs. This patch adds the IORESOURCE_RESERVE flag to the APIC and MMCONF resource flags to do this. I also added a new resource for the mapped bios rom area just below 4GB. I'm not sure if the choice for the index parameter of new_resource() is correct though. Note that the bios rom decode is enabled in src/southbridge/via/vt8237r/vt8237r_early_smbus.c for the whole 4MB area (even though the comment says 1MB). Signed-off-by: Tobias Diedrich ranma+coreb...@tdiedrich.de --- Index: coreboot-svn-m2v-splitpatches/src/southbridge/via/k8t890/k8t890_traf_ctrl.c === --- coreboot-svn-m2v-splitpatches.orig/src/southbridge/via/k8t890/k8t890_traf_ctrl.c 2010-11-03 21:38:32.0 +0100 +++ coreboot-svn-m2v-splitpatches/src/southbridge/via/k8t890/k8t890_traf_ctrl.c 2010-11-03 21:45:21.0 +0100 @@ -58,7 +58,7 @@ res-limit = res-base + res-size - 1; res-align = 8; res-gran = 8; - res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | + res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_RESERVE | IORESOURCE_STORED | IORESOURCE_ASSIGNED; /* Add an MMCONFIG resource. */ @@ -67,7 +67,7 @@ res-align = log2(res-size); res-gran = log2(res-size); res-limit = 0x;/* 4G */ - res-flags = IORESOURCE_MEM; + res-flags = IORESOURCE_MEM | IORESOURCE_RESERVE; } static void traf_ctrl_enable_generic(struct device *dev) Index: coreboot-svn-m2v-splitpatches/src/southbridge/via/vt8237r/vt8237r_lpc.c === --- coreboot-svn-m2v-splitpatches.orig/src/southbridge/via/vt8237r/vt8237r_lpc.c 2010-11-03 21:50:45.0 +0100 +++ coreboot-svn-m2v-splitpatches/src/southbridge/via/vt8237r/vt8237r_lpc.c 2010-11-03 21:58:52.0 +0100 @@ -566,7 +566,15 @@ res-limit = 0xUL; res-align = 8; res-gran = 8; - res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | + res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_RESERVE | +IORESOURCE_STORED | IORESOURCE_ASSIGNED; + + /* Fixed flashrom resource */ + res = new_resource(dev, 4); + res-base = 0xffc0UL; + res-size = 0x0040UL; /* 4MB */ + res-limit = 0xUL; + res-flags = IORESOURCE_MEM | IORESOURCE_FIXED | IORESOURCE_RESERVE | IORESOURCE_STORED | IORESOURCE_ASSIGNED; res = new_resource(dev, 1); -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised)
-Original Message- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] Sent: Wednesday, November 03, 2010 01:14 PM To: Scott Duplichan Cc: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised) ]Hi Scott, ] ]I am not totally convinced that all changes are a net win. Hello Carl-Daniel, Thanks for looking at it. The strategy I used is to try to make the code match the current AMD CIMx code as closely as possible. The existing RS780 code is based on an older CIMx version that does not support the family 10h processor. I actually did many experiments with a reference BIOS as a way to find what parts of the code are essential for getting Win7 booted. It is interesting to know that much of the code is not needed for Win7 boot or even for video playback using windows media player. An example is the code that copies some of the processor memory controller settings to the RS780. What is this code for then? Possibly it becomes important for some directX or 3D operation that I did not exercise. I did not test any 3D application. ]On 03.11.2010 05:29, Scott Duplichan wrote: ] (Re-submitting with correction to GFX debug bar setup procedure needed ] for use with AMD family 0Fh processor). ] ] This patch solves crashes and BSODs that occur when booting Win7 with ] AMD RS780 uma graphics. Tested with frame buffer sizes 64m through 1GB ] by running dxdiag and Windows media player at 1600x1200 true color. ] Additional changes needed to boot Win7 on Mahogany_fam10 will follow. ] ] -- Enable and program the debug bar as required by the ATI graphics driver. ]First, make the debug bar writable and allow resource allocation code ]to program it. Once programmed, enable its operation. ] ] ]Good. ] ] ] -- Disable the family 10h processor mmconf while the RS780 mmconf is in use. ] ] ]I thought the family 10h processors need their own MMCONF for some ]configuration accesses. If this disable happens after all such config ]writes are done, I'm OK with it. The family 10h mmconf is disabled only temporarily, then restored to its previous state. I added this code because that is how the current CIMx code does it. ] -- Make strap programming more closely follow the reference BIOS. ] ] ]Good. ] ] ] -- Disable PCIe bar 3 after using it. ] ] ]This one is something I have reservations about. Isn't PCIe BAR 3 the ]one via which MMCONF accesses are done? How is MMCONF going to work ]after that? Of the two reference BIOS binaries I can boot, neither appears to leave PCIe bar 3 enabled. I see zeros there after booting, although I am not 100% sure this means zero is its real value. Yet on the two reference BIOS images, along with the patched coreboot, I can still see the RS780 at mmconf+0. I assume the family 10h processor sends mmconf requests to the HT link if the address is not that of an internal device. I don't know how it works for family 0Fh processors. The original coreboot RS780 code intended to disable BAR 3 after using it. The code comment reads, We should disable bar3 when we want to exit rs780_enable, because bar3 will be remapped in set_resource later. However, the call to the disable function was removed and replaced by this comment: Don't call disable_pcie_bar3(nb_dev) here, otherwise the screen will crash. I debugged this problem and found the disable function set the bar to zero, but did not disable it. So legacy video MMIO writes were being claimed by bar 3 and not reaching the video function. The patch corrects this problem and adds back the function call to disable bar 3 after PCIe training is complete. The reason I even looked at this code in the first place is this. With the unpatched code, the PCI resource allocation code finds bar 3 writable and assigns it a base address. In my case it assigned C000. This C00 range is unusable because it is not the range set aside for mmconf. I have mmconf at F800. In addition, I noticed the mahogany_fam10 and mahogany projects have no MCFG table, so Windows will never use mmconf for PCI config access. This is an area I would like to study more, but any improvement should probably be done in a separate patch. It is interesting to know that Microsoft planned for mmconf and the ACPI MCFG table to be required for Windows Vista. The early beta editions required it. But it proved too much trouble and the requirement was removed. The requirement was not added back for Win7. I don't know if it is planned for Win8. ] -- UMA size is no longer hardcoded. ] ] ]Nice. ] ] ] -- Disable write combining for all steppings to eliminate stability problem. ] ] ]This may have a performance impact, right? Do you know if any steppings ]with stable write combining exist? Write combining should only be disabled for the early steppings. Why I have to disable it for A13 is an unsolved problem. Yes, I would assume there is a performance impact. On the otherhand, using the ATI driver
Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised)
Hi Scott, I tried to boot with that on famF CPU and it went well. ruiktest:~# ruiktest:~# lspci -vvv -s 01:05.0 01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4200] (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 1000 [size=256] Region 2: Memory at f810 (32-bit, non-prefetchable) [size=64K] Region 5: Memory at f800 (32-bit, non-prefetchable) [size=1M] Expansion ROM at unassigned [disabled] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Kernel driver in use: radeon The BAR seems to be enabled. Btw I tried to boot Win7 but still got only logo animation forever. Not sure what it could be. I agree that this patch is big improvement. We can fix the MMCONF later. Thanks, Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r6017 - in trunk/src/superio/fintek: . f71889
Author: uwe
Date: Wed Nov 3 22:46:41 2010
New Revision: 6017
URL: https://tracker.coreboot.org/trac/coreboot/changeset/6017
Log:
Add Fintek F71889 Super I/O support.
Untested, but should work mostly (even though some TODOs remain).
Signed-off-by: Alec Ari neotheu...@ymail.com
Acked-by: Uwe Hermann u...@hermann-uwe.de
Added:
trunk/src/superio/fintek/f71889/
trunk/src/superio/fintek/f71889/Makefile.inc
trunk/src/superio/fintek/f71889/chip.h
trunk/src/superio/fintek/f71889/f71889.h
trunk/src/superio/fintek/f71889/f71889_early_serial.c
trunk/src/superio/fintek/f71889/superio.c
Modified:
trunk/src/superio/fintek/Kconfig
trunk/src/superio/fintek/Makefile.inc
Modified: trunk/src/superio/fintek/Kconfig
==
--- trunk/src/superio/fintek/KconfigWed Nov 3 14:24:29 2010(r6016)
+++ trunk/src/superio/fintek/KconfigWed Nov 3 22:46:41 2010(r6017)
@@ -4,3 +4,5 @@
bool
config SUPERIO_FINTEK_F71859
bool
+config SUPERIO_FINTEK_F71889
+ bool
Modified: trunk/src/superio/fintek/Makefile.inc
==
--- trunk/src/superio/fintek/Makefile.inc Wed Nov 3 14:24:29 2010
(r6016)
+++ trunk/src/superio/fintek/Makefile.inc Wed Nov 3 22:46:41 2010
(r6017)
@@ -1,3 +1,4 @@
subdirs-y += f71805f
subdirs-y += f71863fg
subdirs-y += f71859
+subdirs-y += f71889
Added: trunk/src/superio/fintek/f71889/Makefile.inc
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ trunk/src/superio/fintek/f71889/Makefile.incWed Nov 3 22:46:41
2010(r6017)
@@ -0,0 +1,22 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2010 Alec Ari neotheu...@ymail.com
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+##
+
+ramstage-$(CONFIG_SUPERIO_FINTEK_F71889) += superio.c
+
Added: trunk/src/superio/fintek/f71889/chip.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ trunk/src/superio/fintek/f71889/chip.h Wed Nov 3 22:46:41 2010
(r6017)
@@ -0,0 +1,30 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Alec Ari neotheu...@ymail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include pc80/keyboard.h
+#include device/device.h
+#include uart8250.h
+
+extern struct chip_operations superio_fintek_f71889_ops;
+
+struct superio_fintek_f71889_config {
+ struct uart8250 com1, com2;
+ struct pc_keyboard keyboard;
+};
Added: trunk/src/superio/fintek/f71889/f71889.h
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ trunk/src/superio/fintek/f71889/f71889.hWed Nov 3 22:46:41 2010
(r6017)
@@ -0,0 +1,32 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Alec Ari neotheu...@ymail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU
Re: [coreboot] F71889 Super I/O patch
On Wed, Nov 03, 2010 at 12:18:56PM -0700, Neo The User wrote: Signed-off-by: Alec Ari neotheu...@ymail.com Thanks, committed in r6017 with a few changes: - Changed unsigned int etc. to u8/u16 etc. everywhere. - Add the missing LDNs as per datasheet to f71889.h and added superio.c code to handle the devices (at least partially). - Add KBC stuff, this Super I/O _does_ have a keyboard LDN. - Fixed up pnp_dev_info as good as possible, but it seems the datasheet is missing some info needed to asses where to use 0x7f8 or 0xff8 etc. the code off the other 785 boards. If anybody wants to test the F71889 patch, feel free. Yup, but testing is not strictly required, I'm relatively sure the code as committed should work (though there are some TODOs). Also I wasn't sure to keep the same name in the other Fintek chips or not, so I changed the name to mine, and the Yep, that's fine for such simple pieces of code which cannot be written much differently anyways. But please do keep the (C) lines intact when deriving/copying larger and more complex pieces of code. year. I apologize if that was incorrect, and will be more than willing to keep the original GNU header. There's no such thing as a GNU header btw. Every file has one or more (C) Copyright line(s) which list the copyright holder(s) and the resp. years, and a text-blob which describes the license that applies to that file (in this case it happens to be the GNU GPL). Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] ACPI: XP doesn't like qwords...
Since XP only implements parts of ACPI 2.0, it chokes on the TOM2 qword in the
SSDT, which is present if a board uses k8acpi_write_vars.
With the acpigen_write_name_qword(TOM2... in place I get a
Stop A5 (0x11, 0x8, virtual address of SSDT, somevalue)
bluescreen on boot.
This patch replaces the qword with a dword, which contains (TOM2 20),
giving us 1MB granularity and a limit of almost 4Exabyte of memory.
I added corresponding ShiftLeft calls in the commented out dsdt
sections that would use TOM2 if they were not commented out.
This problem was introduced with
http://tracker.coreboot.org/trac/coreboot/changeset/3953
Note that all corresponding DSDTs currently only ever check TOM2 against 0.
Signed-off-by: Tobias Diedrich ranma+coreb...@tdiedrich.de
---
Index: src/northbridge/amd/amdk8/amdk8_acpi.c
===
--- src/northbridge/amd/amdk8/amdk8_acpi.c.orig 2010-11-03 23:19:03.0
+0100
+++ src/northbridge/amd/amdk8/amdk8_acpi.c 2010-11-03 23:19:37.0
+0100
@@ -270,7 +270,15 @@
msr = rdmsr(TOP_MEM);
lens += acpigen_write_name_dword(TOM1, msr.lo);
msr = rdmsr(TOP_MEM2);
- lens += acpigen_write_name_qword(TOM2, (((uint64_t) msr.hi) 32) |
msr.lo);
+ /*
+* Since XP only implements parts of ACPI 2.0, we can't use a qword
+* here.
+* See http://www.acpi.info/presentations/S01USMOBS169_OS%2520new.ppt
+* slide 22ff.
+* Shift value right by 20 bit to make it fit into 32bit,
+* giving us 1MB granularity and a limit of almost 4Exabyte of memory.
+*/
+ lens += acpigen_write_name_dword(TOM2, (msr.hi 12) | msr.lo 20);
lens += k8acpi_write_HT();
//minus opcode
Index: src/mainboard/gigabyte/ma78gm/dsdt.asl
===
--- src/mainboard/gigabyte/ma78gm/dsdt.asl.orig 2010-11-03 23:19:03.0
+0100
+++ src/mainboard/gigabyte/ma78gm/dsdt.asl 2010-11-03 23:19:37.0
+0100
@@ -1168,7 +1168,7 @@
/* Note: Only need HID on Primary Bus */
Device(PCI0) {
External (TOM1)
- External (TOM2)
+ External (TOM2) /* (real tom2 20) to make it fit
into 32 bit for XP */
Name(_HID, EISAID(PNP0A03))
Name(_ADR, 0x0018) /* Dev# = BSP Dev#, Func# = 0 */
Method(_BBN, 0) { /* Bus number = 0 */
@@ -1614,7 +1614,8 @@
/*
* If(LNotEqual(TOM2, 0x)){
* Store(0x1,DMHB)
DRAM from 4GB to TopMem2
- * Subtract(TOM2, 0x1, DMHL)
+ * ShiftLeft(TOM2, 20, Local0)
+ * Subtract(Local0, 0x1, DMHL)
* }
*/
Index: src/mainboard/asrock/939a785gmh/dsdt.asl
===
--- src/mainboard/asrock/939a785gmh/dsdt.asl.orig 2010-11-03
23:19:28.0 +0100
+++ src/mainboard/asrock/939a785gmh/dsdt.asl2010-11-03 23:19:37.0
+0100
@@ -1122,7 +1122,7 @@
/* Note: Only need HID on Primary Bus */
Device(PCI0) {
External (TOM1)
- External (TOM2)
+ External (TOM2) /* (real tom2 20) to make it fit
into 32 bit for XP */
Name(_HID, EISAID(PNP0A03))
Name(_ADR, 0x0018) /* Dev# = BSP Dev#, Func# = 0 */
Method(_BBN, 0) { /* Bus number = 0 */
@@ -1530,7 +1530,8 @@
/*
* If(LNotEqual(TOM2, 0x)){
* Store(0x1,DMHB)
DRAM from 4GB to TopMem2
- * Subtract(TOM2, 0x1, DMHL)
+ * ShiftLeft(TOM2, 20, Local0)
+ * Subtract(Local0, 0x1, DMHL)
* }
*/
Index: src/mainboard/kontron/kt690/dsdt.asl
===
--- src/mainboard/kontron/kt690/dsdt.asl.orig 2010-11-03 23:19:28.0
+0100
+++ src/mainboard/kontron/kt690/dsdt.asl2010-11-03 23:19:37.0
+0100
@@ -1129,7 +1129,7 @@
/* Note: Only need HID on Primary Bus */
Device(PCI0) {
External (TOM1)
- External (TOM2)
+ External (TOM2) /* (real tom2 20) to make it fit
into 32 bit for XP */
Name(_HID, EISAID(PNP0A03))
Re: [coreboot] [patch] fix unexpacted MTRR setup for UMA memory
Hi, I just want to tell me too, so question is we go to direction of claiming less ram_resource as intel do or others. Is the AMD uma limited to 4GB? Thanks, Rudolf -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] Geode GX2 print(k)
Remove banner wrapper function and unify print(k).
Signed-off-by: Nils Jacobs njaco...@hetnet.nl
The banner part was requested by Uwe.
This is Abuild and boot tested.
Thanks, Nils.
Index: src/northbridge/amd/gx2/raminit.c
===
--- src/northbridge/amd/gx2/raminit.c (revision 6017)
+++ src/northbridge/amd/gx2/raminit.c (working copy)
@@ -26,20 +26,15 @@
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
};
-static void banner(const char *s)
-{
- printk(BIOS_DEBUG, * %s\n, s);
-}
-
static void hcf(void)
{
- print_emerg(DIE\n);
+ printk(BIOS_EMERG, DIE\n);
/* this guarantees we flush the UART fifos (if any) and also
* ensures that things, in general, keep going so no debug output
* is lost
*/
while (1)
- print_emerg_char(0);
+ printk(BIOS_EMERG, (0));
}
static void auto_size_dimm(unsigned int dimm)
@@ -51,35 +46,35 @@
dimm_setting = 0;
- banner(Check present);
+ printk(BIOS_DEBUG, Check present\n);
/* Check that we have a dimm */
if (spd_read_byte(dimm, SPD_MEMORY_TYPE) == 0xFF) {
return;
}
- banner(MODBANKS);
+ printk(BIOS_DEBUG, MODBANKS\n);
/* Field: Module Banks per DIMM */
/* EEPROM byte usage: (5) Number of DIMM Banks */
spd_byte = spd_read_byte(dimm, SPD_NUM_DIMM_BANKS);
if ((MIN_MOD_BANKS spd_byte) || (spd_byte MAX_MOD_BANKS)) {
- print_emerg(Number of module banks not compatible\n);
+ printk(BIOS_EMERG, Number of module banks not compatible\n);
post_code(ERROR_BANK_SET);
hcf();
}
dimm_setting |= (spd_byte 1) CF07_UPPER_D0_MB_SHIFT;
- banner(FIELDBANKS);
+ printk(BIOS_DEBUG, FIELDBANKS\n);
/* Field: Banks per SDRAM device */
/* EEPROM byte usage: (17) Number of Banks on SDRAM Device */
spd_byte = spd_read_byte(dimm, SPD_NUM_BANKS_PER_SDRAM);
if ((MIN_DEV_BANKS spd_byte) || (spd_byte MAX_DEV_BANKS)) {
- print_emerg(Number of device banks not compatible\n);
+ printk(BIOS_EMERG, Number of device banks not compatible\n);
post_code(ERROR_BANK_SET);
hcf();
}
dimm_setting |= (spd_byte 2) CF07_UPPER_D0_CB_SHIFT;
- banner(SPDNUMROWS);
+ printk(BIOS_DEBUG, SPDNUMROWS\n);
/* Field: DIMM size
* EEPROM byte usage:
* (3) Number of Row Addresses
@@ -90,29 +85,29 @@
*/
if ((spd_read_byte(dimm, SPD_NUM_ROWS) 0xF0)
|| (spd_read_byte(dimm, SPD_NUM_COLUMNS) 0xF0)) {
- print_emerg(Assymetirc DIMM not compatible\n);
+ printk(BIOS_EMERG, Assymetirc DIMM not compatible\n);
post_code(ERROR_UNSUPPORTED_DIMM);
hcf();
}
- banner(SPDBANKDENSITY);
+ printk(BIOS_DEBUG, SPDBANKDENSITY\n);
dimm_size = spd_read_byte(dimm, SPD_BANK_DENSITY);
- banner(DIMMSIZE);
+ printk(BIOS_DEBUG, DIMMSIZE\n);
dimm_size |= (dimm_size 8); /* align so 1GB(bit0) is bit 8, this is a little weird to get gcc to not optimize this out */
dimm_size = 0x01FC; /* and off 2GB DIMM size : not supported and the 1GB size we just moved up to bit 8 as well as all the extra on top */
/* Module Density * Module Banks */
dimm_size = (dimm_setting CF07_UPPER_D0_MB_SHIFT) 1; /* shift to multiply by # DIMM banks */
- banner(BEFORT CTZ);
+ printk(BIOS_DEBUG, BEFORT CTZ\n);
dimm_size = __builtin_ctz(dimm_size);
- banner(TEST DIMM SIZE7);
+ printk(BIOS_DEBUG, TEST DIMM SIZE7\n);
if (dimm_size 7) { /* 7 is 512MB only support 512MB per DIMM */
- print_emerg(Only support up to 512MB per DIMM\n);
+ printk(BIOS_EMERG, Only support up to 512MB per DIMM\n);
post_code(ERROR_DENSITY_DIMM);
hcf();
}
dimm_setting |= dimm_size CF07_UPPER_D0_SZ_SHIFT;
- banner(PAGESIZE);
+ printk(BIOS_DEBUG, PAGESIZE\n);
/*
* Field: PAGE size
@@ -142,22 +137,22 @@
*/
spd_byte = NumColAddr[spd_read_byte(dimm, SPD_NUM_COLUMNS) 0xF];
- banner(MAXCOLADDR);
+ printk(BIOS_DEBUG, MAXCOLADDR\n);
if (spd_byte MAX_COL_ADDR) {
- print_emerg(DIMM page size not compatible\n);
+ printk(BIOS_EMERG, DIMM page size not compatible\n);
post_code(ERROR_SET_PAGE);
hcf();
}
- banner(11address test);
+ printk(BIOS_DEBUG, 11address test\n);
spd_byte -= 7;
if (spd_byte 4) { /* if the value is above 4 it means 11 col address lines */
spd_byte = 7; /* which means 16k so set to disabled */
}
dimm_setting |= spd_byte CF07_UPPER_D0_PSZ_SHIFT; /* 0=1k,1=2k,2=4k,etc */
- banner(RDMSR CF07);
+ printk(BIOS_DEBUG, RDMSR CF07\n);
msr = rdmsr(MC_CF07_DATA);
- banner(WRMSR CF07);
+ printk(BIOS_DEBUG, WRMSR CF07\n);
if (dimm == DIMM0) {
msr.hi = 0x;
msr.hi |= dimm_setting;
@@ -166,7 +161,7 @@
msr.hi |= dimm_setting 16;
}
wrmsr(MC_CF07_DATA, msr);
- banner(ALL DONE);
+ printk(BIOS_DEBUG, ALL DONE\n);
}
static void checkDDRMax(void)
@@ -194,7 +189,7 @@
/* current speed max speed? */
if (GeodeLinkSpeed() speed) {
- print_emerg(DIMM overclocked. Check GeodeLink Speed\n);
+ printk(BIOS_EMERG, DIMM overclocked. Check GeodeLink Speed\n);
post_code(POST_PLL_MEM_FAIL);
hcf();
}
@@ -311,7 +306,7 @@
} else if ((casmap0 = casmap1)) {
Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems in Win7 (revised)
On Wed, Nov 3, 2010 at 3:34 PM, Rudolf Marek r.ma...@assembler.cz wrote: Hi Scott, I tried to boot with that on famF CPU and it went well. ruiktest:~# ruiktest:~# lspci -vvv -s 01:05.0 01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD 4200] (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 18 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 1000 [size=256] Region 2: Memory at f810 (32-bit, non-prefetchable) [size=64K] Region 5: Memory at f800 (32-bit, non-prefetchable) [size=1M] Expansion ROM at unassigned [disabled] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: Data: Kernel driver in use: radeon The BAR seems to be enabled. Btw I tried to boot Win7 but still got only logo animation forever. Not sure what it could be. I agree that this patch is big improvement. We can fix the MMCONF later. Was that an ack? Maybe I misunderstand, but I don't think that there is an MMCONF issue. The bar disable prevents the 780 MMCONF from being moved, right? Just curious, have you test this with Linux? I tried to load win7, but got a ACPI stop 0xA5. I suspect that my tables are not working at all. This is on iei kino. I will investigate more tomorrow. Marc -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] EPIA halting after vt8601 init
On Wed, Nov 03, 2010 at 03:00:54PM -0600, Myles Watson wrote:
Is this rom structure reasonable (missing fallback/romstage?):
It's fine. The romstage (boot block) isn't part of CBFS.
Loading stage image.
Check CBFS header at hangs here
Normally a hang here means that the whole ROM isn't mapped, so trying
to read from the top of the ROM hangs, even though the bootblock
accesses work fine.
Yup, sounds like that's the problem. Here's a quick patch to fix it
by adding a rom_enable() function (and converting VT8231 to
TINYBOOTBLOCK) while I'm at it. The only problem: It won't compile ;)
ROMCC romstage.inc
mtrr.h:73.42:
non const static variables not supported
make: *** [build/mainboard/via/epia/romstage.inc] Error 1
No time to investigate right now, if someone else sees the problem,
please feel free to fix and commit. Probably just some missing
#if defined(ROMCC) or the like.
Uwe.
--
http://hermann-uwe.de | http://sigrok.org
http://randomprojects.org | http://unmaintained-free-software.org
ROM enable function for VIA VT8231, convert it to TINYBOOTBLOCK.
- Adding the ROM enable function is required (very early) since CBFS,
otherwise the boot process will hang.
- The Map 4MB of FLASH into the address space code in vt8231_lpc.c looks
incorrect, that register does something completely different according
to the VT8231 datasheet (probably copypaste from another VIA SB).
The new enable_rom() should do the right thing, so drop the old code.
- While we're at it, convert the VT8231 to TINYBOOTBLOCK, too.
Signed-off-by: Uwe Hermann u...@hermann-uwe.de
Index: src/southbridge/via/vt8231/bootblock.c
===
--- src/southbridge/via/vt8231/bootblock.c (Revision 0)
+++ src/southbridge/via/vt8231/bootblock.c (Revision 0)
@@ -0,0 +1,26 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Uwe Hermann u...@hermann-uwe.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include southbridge/via/vt8231/vt8231_enable_rom.c
+
+static void bootblock_southbridge_init(void)
+{
+ vt8231_enable_rom();
+}
Index: src/southbridge/via/vt8231/Kconfig
===
--- src/southbridge/via/vt8231/Kconfig (Revision 6016)
+++ src/southbridge/via/vt8231/Kconfig (Arbeitskopie)
@@ -20,3 +20,10 @@
config SOUTHBRIDGE_VIA_VT8231
bool
select HAVE_DEBUG_SMBUS
+ select TINY_BOOTBLOCK
+
+config BOOTBLOCK_SOUTHBRIDGE_INIT
+ string
+ default southbridge/via/vt8231/bootblock.c
+ depends on SOUTHBRIDGE_VIA_VT8231
+
Index: src/southbridge/via/vt8231/vt8231_lpc.c
===
--- src/southbridge/via/vt8231/vt8231_lpc.c (Revision 6016)
+++ src/southbridge/via/vt8231/vt8231_lpc.c (Arbeitskopie)
@@ -61,9 +61,6 @@
enables |= 0x80;
pci_write_config8(dev, 0x6C, enables);
- // Map 4MB of FLASH into the address space
- pci_write_config8(dev, 0x41, 0x7f);
-
// Set bit 6 of 0x40, because Award does it (IO recovery time)
// IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI
// interrupts can be properly marked as level triggered.
Index: src/southbridge/via/vt8231/vt8231_enable_rom.c
===
--- src/southbridge/via/vt8231/vt8231_enable_rom.c (Revision 0)
+++ src/southbridge/via/vt8231/vt8231_enable_rom.c (Revision 0)
@@ -0,0 +1,47 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2010 Uwe Hermann u...@hermann-uwe.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems inWin7 (revised)
-Original Message-
From: coreboot-boun...@coreboot.org [mailto:coreboot-boun...@coreboot.org] On
Behalf Of Marc Jones
Sent: Wednesday, November 03, 2010 06:53 PM
To: Rudolf Marek
Cc: coreboot@coreboot.org
Subject: Re: [coreboot] [PATCH] Fix AMD HD 3200 uma graphics problems inWin7
(revised)
]On Wed, Nov 3, 2010 at 3:34 PM, Rudolf Marek r.ma...@assembler.cz wrote:
] Hi Scott,
]
] I tried to boot with that on famF CPU and it went well.
] ruiktest:~#
] ruiktest:~# lspci -vvv -s 01:05.0
]
] 01:05.0 VGA compatible controller: ATI Technologies Inc RS880 [Radeon HD
] 4200] (prog-if 00 [VGA controller])
] Subsystem: ATI Technologies Inc Device
] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
] Stepping- SERR- FastB2B- DisINTx-
] Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
] TAbort- MAbort- SERR- PERR- INTx-
] Latency: 0, Cache Line Size: 64 bytes
] Interrupt: pin A routed to IRQ 18
] Region 0: Memory at e800 (32-bit, prefetchable) [size=128M]
] Region 1: I/O ports at 1000 [size=256]
] Region 2: Memory at f810 (32-bit, non-prefetchable) [size=64K]
] Region 5: Memory at f800 (32-bit, non-prefetchable) [size=1M]
] Expansion ROM at unassigned [disabled]
] Capabilities: [50] Power Management version 3
] Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
] PME(D0-,D1-,D2-,D3hot-,D3cold-)
] Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
] Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
] Address: Data:
] Kernel driver in use: radeon
]
] The BAR seems to be enabled. Btw I tried to boot Win7 but still got only
] logo animation forever. Not sure what it could be.
]
] I agree that this patch is big improvement. We can fix the MMCONF later.
]
]Was that an ack?
]
]Maybe I misunderstand, but I don't think that there is an MMCONF
]issue. The bar disable prevents the 780 MMCONF from being moved,
]right?
]
]Just curious, have you test this with Linux?
Slax 6.12 live CD - Good. Using I/O APIC interrupts.
Linuxmint 9 live CD - Good. Using I/O APIC interrupts.
DSL linux live CD - Flood of APIC error on CPU0: 40(40)
I believe if SB700 ioxapic mode is not enabled everything is good.
WinXP x64 SP2 setup CD - An unexpected error (805246152) occurred at line
1831 in d:\nt\base\boot\setup\arcdisp.c
WinXP x86 SP3 setup CD - An unexpected error (805246152) occurred at line
1831 in d:\nt\base\boot\setup\arcdisp.c
Win7 x64 Ultimate setup DVD - setup completed quickly with zero problems.
All testing is with UMA graphics. I build the mahogany_fam10 project and
run it on an ECS A780GM-M3 board.
]I tried to load win7, but
]got a ACPI stop 0xA5. I suspect that my tables are not working at all.
]This is on iei kino. I will investigate more tomorrow.
The attached patch contains work in progress changes outside of the
previously RS780 patch. Apply it to the latest trunk code along with
the RS780 patch. This patch is good only for mahogany_fam10, not for
mahogany (family 0Fh). The ACPI changes need to be ported from family
10h to family 0Fh. Based on what Rudolf said recently, the family 0Fh
project method of passing TOM1 etc to ACPI is the preferred way, not
the family 10h method.
Use 1 or 2 GB of memory. Three should also work, although I am not sure
the memory init code can handle 3GB. As I recall memory above 4GB is
not yet handled correctly for booting Win7.
Hopefully you can just build a mahogany_fam10 binary and run it on Kino.
Probably any RS780 video option rom will get the job done.
Thanks,
Scott
]Marc
]
]--
]http://se-eng.com
Index: src/arch/i386/boot/coreboot_table.c
===
--- src/arch/i386/boot/coreboot_table.c (revision 6017)
+++ src/arch/i386/boot/coreboot_table.c (working copy)
@@ -488,18 +488,18 @@
return mem;
}
-static void lb_add_rsvd_range(void *gp, struct device *dev, struct resource
*res)
+static void lb_remove_rsvd_range(void *gp, struct device *dev, struct resource
*res)
{
struct lb_memory *mem = gp;
- lb_add_memory_range(mem, LB_MEM_RESERVED, res-base, res-size);
+ lb_remove_memory_range(mem, res-base, res-size);
}
-static void add_lb_reserved(struct lb_memory *mem)
+static void remove_lb_reserved(struct lb_memory *mem)
{
- /* Add reserved ranges */
+ /* Remove reserved ranges */
search_global_resources(
IORESOURCE_MEM | IORESOURCE_RESERVE, IORESOURCE_MEM |
IORESOURCE_RESERVE,
- lb_add_rsvd_range, mem);
+ lb_remove_rsvd_range, mem);
}
#if CONFIG_WRITE_HIGH_TABLES == 1
@@ -576,8 +576,8 @@
high_tables_base, high_tables_size);
#endif
- /* Add reserved regions */
- add_lb_reserved(mem);
+ /* Remove reserved regions */
+
Re: [coreboot] [PATCH] don't print too early on mcp55-based boards
Sent from my mobile phone On 03.11.2010, at 09:56, Ward Vandewege w...@gnu.org wrote: On Tue, Nov 02, 2010 at 11:20:43PM +0100, Uwe Hermann wrote: I don't object to the patch, and we should probably fix this in all other southbridges, I think the same problem applies there. But: the die() call itself also does a printk(), so that'll still hang if the error path is chosen (at that point it probably doesn't matter much, though, as we die anyway). Right, I think it does not matter. If the die happens when printk is already functional, great, if not it will hang there which is fine. I also agree that die() should have a POST code, preferrably something easy to remember. It already has a commented-out //post_code(0xff);. Not sure why it's disabled, but I think it should be something other than 0xff, that's a bit too special for my taste. We have 0xee: Not supposed to get here as per documentation/POSTCODES, so maybe we can use 0xdd (d as in die), if that's not already used elsewhere. So, thinking about this a little more, I'm not sure adding a post code to 'die' is a good idea. The problem with doing that is that it would clobber any previous post codes, which might be a better indicator for what's going wrong. Perhaps a good way to deal with fatal runtime error conditions would be a) set a unique post code b) call die in the assumption that die does not clobber the post code. We could add a post code to the parameters of the die() function. What do you think? Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
