This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
On Sun, May 10, 2009 at 8:21 AM, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
Acked-by: Corey Osgood corey.osgood@gmail.com
Where did you find the info on configuring the BUFF_SC registers? Also, the lack of high tables breaks something (SeaBIOS or CBFS?) but I haven't been following close enough lately to remember what.
-Corey
On Sun, May 10, 2009 at 8:48 PM, Corey Osgood corey.osgood@gmail.comwrote:
On Sun, May 10, 2009 at 8:21 AM, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
Acked-by: Corey Osgood corey.osgood@gmail.com
thanks.
Where did you find the info on configuring the BUFF_SC registers? Also, the lack of high tables breaks something (SeaBIOS or CBFS?) but I haven't been following close enough lately to remember what.
-Corey
A lot of RE, comparing and matching my values from different DIMMs, and ofcourse - trying to make some sense from various documentation...
Elia.
here is the comment from my previous patch, revealing most of my RE work :
/* TODO: This needs to be calculated according to the DRAM tech * (x8, x16, or x32). Argh, Intel provides no docs on this! * Currently, it needs to be pulled from the output of * lspci -xxx Rx92 * here are some common results: * (c = 128MB dual sided, d = 128MB single sided, f = 256MB dual sided) * BUFF_SC: tom: drp: DIMM0: DIMM1: * 0x3356 128MB 0x0c 128MB dual-sided - * 0xcc56 128MB 0xc0 - 128MB dual-sided * 0x77da 128MB 0x0d 128MB single-sided - * 0xddda 128MB 0xd0 - 128MB single-sided * 0x0001 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 256MB 0x0f 256MB dual-sided - * 0xcc56 256MB 0xf0 - 256MB dual-sided * 0x0001 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 512MB 0xff 256MB dual-sided 256MB dual-sided * * BUFF_SC: BUFF_SC in binary: tom: drp: DIMM0: DIMM1: * 0x3356 0 0 1 1 00 11 01 01 01 10 128MB 0x0c 128MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 128MB 0xc0 - 128MB dual-sided * 0x77da 0 1 1 1 01 11 11 01 10 10 128MB 0x0d 128MB single-sided - * 0xddda 1 1 0 1 11 01 11 01 10 10 128MB 0xd0 - 128MB single-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 0 1 0 1 01 01 11 00 01 10 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 0 0 1 1 00 11 01 01 01 10 256MB 0x0f 256MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 256MB 0xf0 - 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 512MB 0xff 256MB dual-sided 256MB dual-sided
0:1 00 = 0 DIMMs 01 = 2 dual 1 dual + 1 single 1 single + 1 dual 10 = 1 DIMM only 2 single 2:3 00 = 2 dual sided 01 = 1 dual sided only 2 single sided 1 dual + 1 single 1 single + 1 dual 10 = 1 single sided only 4:5 00 = 2 DIMMs 01 = 1 DIMM only 6:7 00 = 2 dual 01 = 1 dual only 1 dual + 1 single 1 single + 1 dual 11 = 1 single 2 single 8:9 00 = 2 dual 1 single + 1 dual 1 dual only in slot #1 01 = 1 single only in slot #1 1 dual + 1 single 2 single 11 = no dimm in slot #1 10:11 00 = 1 dual only in slot #0 2 dual 1 dual + 1 single 01 = 1 single only in slot #0 2 single 1 single + 1 dual 11 = no dimm in slot #0 12 0 = 1 dual only in slot #1 2 dual 1 single + 1 dual 1 = no dimm in slot #1 1 single 2 single 1 dual + 1 single 13 0 = any in slot #1 1 = no dimm in slot #1 14 0 = 1 dual only in slot #0 2 dual 1 dual + 1 single 1 = no dimm in slot #0 1 single only in slot #0 2 single 1 single + 1 dual 15 0 = no dimm in slot #1 2 DIMMs 1 = no dimm in slot #0
*/
On Sun, May 10, 2009 at 6:34 PM, Elia Yehuda z4ziggy@gmail.com wrote:
here is the comment from my previous patch, revealing most of my RE work :
/* TODO: This needs to be calculated according to the DRAM tech * (x8, x16, or x32). Argh, Intel provides no docs on this! * Currently, it needs to be pulled from the output of * lspci -xxx Rx92 * here are some common results: * (c = 128MB dual sided, d = 128MB single sided, f = 256MB dual sided) * BUFF_SC: tom: drp: DIMM0: DIMM1: * 0x3356 128MB 0x0c 128MB dual-sided - * 0xcc56 128MB 0xc0 - 128MB dual-sided * 0x77da 128MB 0x0d 128MB single-sided - * 0xddda 128MB 0xd0 - 128MB single-sided * 0x0001 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 256MB 0x0f 256MB dual-sided - * 0xcc56 256MB 0xf0 - 256MB dual-sided * 0x0001 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 512MB 0xff 256MB dual-sided 256MB dual-sided * * BUFF_SC: BUFF_SC in binary: tom: drp:DIMM0: DIMM1: * 0x3356 0 0 1 1 00 11 01 01 01 10 128MB 0x0c 128MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 128MB 0xc0
128MB dual-sided
- 0x77da 0 1 1 1 01 11 11 01 10 10 128MB 0x0d 128MB
single-sided - * 0xddda 1 1 0 1 11 01 11 01 10 10 128MB 0xd0
128MB single-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 256MB 0xcc 128MB
dual-sided 128MB dual-sided * 0x55c6 0 1 0 1 01 01 11 00 01 10 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 0 0 1 1 00 11 01 01 01 10 256MB 0x0f 256MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 256MB 0xf0
256MB dual-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xcf 256MB
dual-sided 128MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 512MB 0xff 256MB dual-sided 256MB dual-sided
0:1 00 = 0 DIMMs 01 = 2 dual 1 dual + 1 single 1 single + 1 dual 10 = 1 DIMM only 2 single 2:3 00 = 2 dual sided 01 = 1 dual sided only 2 single sided 1 dual + 1 single 1 single + 1 dual 10 = 1 single sided only 4:5 00 = 2 DIMMs 01 = 1 DIMM only 6:7 00 = 2 dual 01 = 1 dual only 1 dual + 1 single 1 single + 1 dual 11 = 1 single 2 single 8:9 00 = 2 dual 1 single + 1 dual 1 dual only in slot #1 01 = 1 single only in slot #1 1 dual + 1 single 2 single 11 = no dimm in slot #1 10:11 00 = 1 dual only in slot #0 2 dual 1 dual + 1 single 01 = 1 single only in slot #0 2 single 1 single + 1 dual 11 = no dimm in slot #0 12 0 = 1 dual only in slot #1 2 dual 1 single + 1 dual 1 = no dimm in slot #1 1 single 2 single 1 dual + 1 single 13 0 = any in slot #1 1 = no dimm in slot #1 14 0 = 1 dual only in slot #0 2 dual 1 dual + 1 single 1 = no dimm in slot #0 1 single only in slot #0 2 single 1 single + 1 dual 15 0 = no dimm in slot #1 2 DIMMs 1 = no dimm in slot #0 */
Wow, cool, I'd never have been able to put that together ;) thanks!
-Corey
On Sun, 10 May 2009 23:09:36 -0400, Corey Osgood corey.osgood@gmail.com wrote:
On Sun, May 10, 2009 at 6:34 PM, Elia Yehuda z4ziggy@gmail.com wrote:
here is the comment from my previous patch, revealing most of my RE work
:
/* TODO: This needs to be calculated according to the DRAM tech * (x8, x16, or x32). Argh, Intel provides no docs on this! * Currently, it needs to be pulled from the output of * lspci -xxx Rx92 * here are some common results: * (c = 128MB dual sided, d = 128MB single sided, f = 256MB dualsided)
* BUFF_SC: tom: drp: DIMM0: DIMM1: * 0x3356 128MB 0x0c 128MB dual-sided - * 0xcc56 128MB 0xc0 - 128MB dual-sided * 0x77da 128MB 0x0d 128MB single-sided - * 0xddda 128MB 0xd0 - 128MB single-sided * 0x0001 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 256MB 0x0f 256MB dual-sided - * 0xcc56 256MB 0xf0 - 256MB dual-sided * 0x0001 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 512MB 0xff 256MB dual-sided 256MB dual-sided * * BUFF_SC: BUFF_SC in binary: tom: drp:DIMM0: DIMM1: * 0x3356 0 0 1 1 00 11 01 01 01 10 128MB 0x0c 128MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 128MB 0xc0
128MB dual-sided
- 0x77da 0 1 1 1 01 11 11 01 10 10 128MB 0x0d 128MB
single-sided - * 0xddda 1 1 0 1 11 01 11 01 10 10 128MB 0xd0
128MB single-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 256MB 0xcc 128MB
dual-sided 128MB dual-sided * 0x55c6 0 1 0 1 01 01 11 00 01 10 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 0 0 1 1 00 11 01 01 01 10 256MB 0x0f 256MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 256MB 0xf0
256MB dual-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xcf 256MB
dual-sided 128MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 512MB 0xff 256MB dual-sided 256MB dual-sided
0:1 00 = 0 DIMMs 01 = 2 dual 1 dual + 1 single 1 single + 1 dual 10 = 1 DIMM only 2 single 2:3 00 = 2 dual sided 01 = 1 dual sided only 2 single sided 1 dual + 1 single 1 single + 1 dual 10 = 1 single sided only 4:5 00 = 2 DIMMs 01 = 1 DIMM only 6:7 00 = 2 dual 01 = 1 dual only 1 dual + 1 single 1 single + 1 dual 11 = 1 single 2 single 8:9 00 = 2 dual 1 single + 1 dual 1 dual only in slot #1 01 = 1 single only in slot #1 1 dual + 1 single 2 single 11 = no dimm in slot #1 10:11 00 = 1 dual only in slot #0 2 dual 1 dual + 1 single 01 = 1 single only in slot #0 2 single 1 single + 1 dual 11 = no dimm in slot #0 12 0 = 1 dual only in slot #1 2 dual 1 single + 1 dual 1 = no dimm in slot #1 1 single 2 single 1 dual + 1 single 13 0 = any in slot #1 1 = no dimm in slot #1 14 0 = 1 dual only in slot #0 2 dual 1 dual + 1 single 1 = no dimm in slot #0 1 single only in slot #0 2 single 1 single + 1 dual 15 0 = no dimm in slot #1 2 DIMMs 1 = no dimm in slot #0 */Wow, cool, I'd never have been able to put that together ;) thanks!
Yes very cool :-) I am going to have to test this out on the i830. Elia do you need someone with svn access to apply your patch?
On Mon, May 11, 2009 at 3:42 PM, Joseph Smith joe@settoplinux.org wrote:
On Sun, 10 May 2009 23:09:36 -0400, Corey Osgood corey.osgood@gmail.com wrote:
On Sun, May 10, 2009 at 6:34 PM, Elia Yehuda z4ziggy@gmail.com wrote:
here is the comment from my previous patch, revealing most of my RE work
:
/* TODO: This needs to be calculated according to the DRAM tech * (x8, x16, or x32). Argh, Intel provides no docs on this! * Currently, it needs to be pulled from the output of * lspci -xxx Rx92 * here are some common results: * (c = 128MB dual sided, d = 128MB single sided, f = 256MB dualsided)
* BUFF_SC: tom: drp: DIMM0: DIMM1: * 0x3356 128MB 0x0c 128MB dual-sided - * 0xcc56 128MB 0xc0 - 128MB dual-sided * 0x77da 128MB 0x0d 128MB single-sided - * 0xddda 128MB 0xd0 - 128MB single-sided * 0x0001 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 256MB 0x0f 256MB dual-sided - * 0xcc56 256MB 0xf0 - 256MB dual-sided * 0x0001 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 512MB 0xff 256MB dual-sided 256MB dual-sided * * BUFF_SC: BUFF_SC in binary: tom: drp:DIMM0: DIMM1: * 0x3356 0 0 1 1 00 11 01 01 01 10 128MB 0x0c 128MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 128MB 0xc0
128MB dual-sided
- 0x77da 0 1 1 1 01 11 11 01 10 10 128MB 0x0d 128MB
single-sided - * 0xddda 1 1 0 1 11 01 11 01 10 10 128MB 0xd0
128MB single-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 256MB 0xcc 128MB
dual-sided 128MB dual-sided * 0x55c6 0 1 0 1 01 01 11 00 01 10 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 0 0 1 1 00 11 01 01 01 10 256MB 0x0f 256MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 256MB 0xf0
256MB dual-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xcf 256MB
dual-sided 128MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 512MB 0xff 256MB dual-sided 256MB dual-sided
0:1 00 = 0 DIMMs 01 = 2 dual 1 dual + 1 single 1 single + 1 dual 10 = 1 DIMM only 2 single 2:3 00 = 2 dual sided 01 = 1 dual sided only 2 single sided 1 dual + 1 single 1 single + 1 dual 10 = 1 single sided only 4:5 00 = 2 DIMMs 01 = 1 DIMM only 6:7 00 = 2 dual 01 = 1 dual only 1 dual + 1 single 1 single + 1 dual 11 = 1 single 2 single 8:9 00 = 2 dual 1 single + 1 dual 1 dual only in slot #1 01 = 1 single only in slot #1 1 dual + 1 single 2 single 11 = no dimm in slot #1 10:11 00 = 1 dual only in slot #0 2 dual 1 dual + 1 single 01 = 1 single only in slot #0 2 single 1 single + 1 dual 11 = no dimm in slot #0 12 0 = 1 dual only in slot #1 2 dual 1 single + 1 dual 1 = no dimm in slot #1 1 single 2 single 1 dual + 1 single 13 0 = any in slot #1 1 = no dimm in slot #1 14 0 = 1 dual only in slot #0 2 dual 1 dual + 1 single 1 = no dimm in slot #0 1 single only in slot #0 2 single 1 single + 1 dual 15 0 = no dimm in slot #1 2 DIMMs 1 = no dimm in slot #0 */Wow, cool, I'd never have been able to put that together ;) thanks!
Yes very cool :-)
thanks :)
I am going to have to test this out on the i830. Elia do you need someone with svn access to apply your patch?
sure, but as was suggested by Myles Watson, we'll wait for the HAVE_HIGH_TABLES fix before applying this patch.
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Elia.
On Mon, May 11, 2009 at 7:30 AM, Elia Yehuda z4ziggy@gmail.com wrote:
On Mon, May 11, 2009 at 3:42 PM, Joseph Smith joe@settoplinux.org wrote:
On Sun, 10 May 2009 23:09:36 -0400, Corey Osgood corey.osgood@gmail.com wrote:
On Sun, May 10, 2009 at 6:34 PM, Elia Yehuda z4ziggy@gmail.com wrote:
here is the comment from my previous patch, revealing most of my RE work
:
/* TODO: This needs to be calculated according to the DRAM tech * (x8, x16, or x32). Argh, Intel provides no docs on this! * Currently, it needs to be pulled from the output of * lspci -xxx Rx92 * here are some common results: * (c = 128MB dual sided, d = 128MB single sided, f = 256MB dual
sided)
* BUFF_SC: tom: drp: DIMM0: DIMM1: * 0x3356 128MB 0x0c 128MB dual-sided - * 0xcc56 128MB 0xc0 - 128MB dual-sided * 0x77da 128MB 0x0d 128MB single-sided - * 0xddda 128MB 0xd0 - 128MB single-sided * 0x0001 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 256MB 0x0f 256MB dual-sided - * 0xcc56 256MB 0xf0 - 256MB dual-sided * 0x0001 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 512MB 0xff 256MB dual-sided 256MB dual-sided * * BUFF_SC: BUFF_SC in binary: tom: drp: DIMM0: DIMM1: * 0x3356 0 0 1 1 00 11 01 01 01 10 128MB 0x0c 128MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 128MB 0xc0
- 128MB dual-sided
* 0x77da 0 1 1 1 01 11 11 01 10 10 128MB 0x0d 128MB single-sided - * 0xddda 1 1 0 1 11 01 11 01 10 10 128MB 0xd0
- 128MB single-sided
* 0x0001 0 0 0 0 00 00 00 00 00 01 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 0 1 0 1 01 01 11 00 01 10 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 0 0 1 1 00 11 01 01 01 10 256MB 0x0f 256MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 256MB 0xf0
- 256MB dual-sided
* 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 512MB 0xff 256MB dual-sided 256MB dual-sided
0:1 00 = 0 DIMMs 01 = 2 dual 1 dual + 1 single 1 single + 1 dual 10 = 1 DIMM only 2 single 2:3 00 = 2 dual sided 01 = 1 dual sided only 2 single sided 1 dual + 1 single 1 single + 1 dual 10 = 1 single sided only 4:5 00 = 2 DIMMs 01 = 1 DIMM only 6:7 00 = 2 dual 01 = 1 dual only 1 dual + 1 single 1 single + 1 dual 11 = 1 single 2 single 8:9 00 = 2 dual 1 single + 1 dual 1 dual only in slot #1 01 = 1 single only in slot #1 1 dual + 1 single 2 single 11 = no dimm in slot #1 10:11 00 = 1 dual only in slot #0 2 dual 1 dual + 1 single 01 = 1 single only in slot #0 2 single 1 single + 1 dual 11 = no dimm in slot #0 12 0 = 1 dual only in slot #1 2 dual 1 single + 1 dual 1 = no dimm in slot #1 1 single 2 single 1 dual + 1 single 13 0 = any in slot #1 1 = no dimm in slot #1 14 0 = 1 dual only in slot #0 2 dual 1 dual + 1 single 1 = no dimm in slot #0 1 single only in slot #0 2 single 1 single + 1 dual 15 0 = no dimm in slot #1 2 DIMMs 1 = no dimm in slot #0
*/
Wow, cool, I'd never have been able to put that together ;) thanks!
Yes very cool :-)
thanks :)
I am going to have to test this out on the i830. Elia do you need someone with svn access to apply your patch?
sure, but as was suggested by Myles Watson, we'll wait for the HAVE_HIGH_TABLES fix before applying this patch.
I don't want to hold back progress. I think you've done good work. Maybe you could send boot logs to the list and get help to track down the error. I don't have the hardware, but I'd be happy to help some. Could you add a few printks to the calculations of tomk before collecting the logs (with and without HAVE_HIGH_TABLES?
Thanks, Myles
On Mon, May 11, 2009 at 4:33 PM, Myles Watson mylesgw@gmail.com wrote:
On Mon, May 11, 2009 at 7:30 AM, Elia Yehuda z4ziggy@gmail.com wrote:
On Mon, May 11, 2009 at 3:42 PM, Joseph Smith joe@settoplinux.org
wrote:
On Sun, 10 May 2009 23:09:36 -0400, Corey Osgood <
corey.osgood@gmail.com>
wrote:
On Sun, May 10, 2009 at 6:34 PM, Elia Yehuda z4ziggy@gmail.com
wrote:
here is the comment from my previous patch, revealing most of my RE work
:
/* TODO: This needs to be calculated according to the DRAM tech * (x8, x16, or x32). Argh, Intel provides no docs on this! * Currently, it needs to be pulled from the output of * lspci -xxx Rx92 * here are some common results: * (c = 128MB dual sided, d = 128MB single sided, f = 256MB dualsided)
* BUFF_SC: tom: drp: DIMM0: DIMM1: * 0x3356 128MB 0x0c 128MB dual-sided - * 0xcc56 128MB 0xc0 - 128MB dual-sided * 0x77da 128MB 0x0d 128MB single-sided - * 0xddda 128MB 0xd0 - 128MBsingle-sided
* 0x0001 256MB 0xcc 128MB dual-sided 128MB dual-sided * 0x55c6 256MB 0xdd 128MB single-sided 128MBsingle-sided
* 0x4445 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 256MB 0xdc 128MB dual-sided 128MBsingle-sided
* 0x3356 256MB 0x0f 256MB dual-sided - * 0xcc56 256MB 0xf0 - 256MB dual-sided * 0x0001 384MB 0xcf 256MB dual-sided 128MB dual-sided * 0x0001 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 384MB 0xdf 256MB dual-sided 128MBsingle-sided
* 0x4445 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 512MB 0xff 256MB dual-sided 256MB dual-sided * * BUFF_SC: BUFF_SC in binary: tom: drp:DIMM0: DIMM1: * 0x3356 0 0 1 1 00 11 01 01 01 10 128MB 0x0c 128MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 128MB 0xc0
128MB dual-sided
- 0x77da 0 1 1 1 01 11 11 01 10 10 128MB 0x0d 128MB
single-sided - * 0xddda 1 1 0 1 11 01 11 01 10 10 128MB 0xd0
128MB single-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 256MB 0xcc 128MB
dual-sided 128MB dual-sided * 0x55c6 0 1 0 1 01 01 11 00 01 10 256MB 0xdd 128MB single-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 256MB 0xcd 128MB single-sided 128MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 256MB 0xdc 128MB dual-sided 128MB single-sided * 0x3356 0 0 1 1 00 11 01 01 01 10 256MB 0x0f 256MB dual-sided - * 0xcc56 1 1 0 0 11 00 01 01 01 10 256MB 0xf0
256MB dual-sided
- 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xcf 256MB
dual-sided 128MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 384MB 0xfc 128MB dual-sided 256MB dual-sided * 0x1145 0 0 0 1 00 01 01 00 01 01 384MB 0xdf 256MB dual-sided 128MB single-sided * 0x4445 0 1 0 0 01 00 01 00 01 01 384MB 0xfd 128MB single-sided 256MB dual-sided * 0x0001 0 0 0 0 00 00 00 00 00 01 512MB 0xff 256MB dual-sided 256MB dual-sided
0:1 00 = 0 DIMMs 01 = 2 dual 1 dual + 1 single 1 single + 1 dual 10 = 1 DIMM only 2 single 2:3 00 = 2 dual sided 01 = 1 dual sided only 2 single sided 1 dual + 1 single 1 single + 1 dual 10 = 1 single sided only 4:5 00 = 2 DIMMs 01 = 1 DIMM only 6:7 00 = 2 dual 01 = 1 dual only 1 dual + 1 single 1 single + 1 dual 11 = 1 single 2 single 8:9 00 = 2 dual 1 single + 1 dual 1 dual only in slot #1 01 = 1 single only in slot #1 1 dual + 1 single 2 single 11 = no dimm in slot #1 10:11 00 = 1 dual only in slot #0 2 dual 1 dual + 1 single 01 = 1 single only in slot #0 2 single 1 single + 1 dual 11 = no dimm in slot #0 12 0 = 1 dual only in slot #1 2 dual 1 single + 1 dual 1 = no dimm in slot #1 1 single 2 single 1 dual + 1 single 13 0 = any in slot #1 1 = no dimm in slot #1 14 0 = 1 dual only in slot #0 2 dual 1 dual + 1 single 1 = no dimm in slot #0 1 single only in slot #0 2 single 1 single + 1 dual 15 0 = no dimm in slot #1 2 DIMMs 1 = no dimm in slot #0 */Wow, cool, I'd never have been able to put that together ;) thanks!
Yes very cool :-)
thanks :)
I am going to have to test this out on the i830. Elia do you need someone with svn access to apply your patch?
sure, but as was suggested by Myles Watson, we'll wait for the HAVE_HIGH_TABLES fix before applying this patch.
I don't want to hold back progress. I think you've done good work. Maybe you could send boot logs to the list and get help to track down the error. I don't have the hardware, but I'd be happy to help some. Could you add a few printks to the calculations of tomk before collecting the logs (with and without HAVE_HIGH_TABLES?
sure. will do it later today and post my logs to the ml. also, uwe is planning to test the patches later today too, so he might be successful in tracing the problem before me :)
Thanks, Myles
Elia.
On Sun, May 10, 2009 at 6:21 AM, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
It looks like the problem is that the memory you're reserving for VGA and the memory reserved for high tables ends up in the same place (ending at tomk.) If you decide which one should go at the end and modify the math, it should work.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com Acked-by: Corey Osgood corey.osgood@gmail.com
Since it looks like an easy fix, let's get it right before committing it. It breaks SeaBIOS, and our assumption that HAVE_HIGH_TABLES doesn't break anything.
Thanks, Myles
On Mon, 11 May 2009 06:52:26 -0600, Myles Watson mylesgw@gmail.com wrote:
On Sun, May 10, 2009 at 6:21 AM, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
It looks like the problem is that the memory you're reserving for VGA and the memory reserved for high tables ends up in the same place (ending at tomk.) If you decide which one should go at the end and modify the math, it should work.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com Acked-by: Corey Osgood corey.osgood@gmail.com
Since it looks like an easy fix, let's get it right before committing it. It breaks SeaBIOS, and our assumption that HAVE_HIGH_TABLES doesn't break anything.
Take a look at how the i945 does this in northbridge.c, It should work here.
On Mon, May 11, 2009 at 3:52 PM, Myles Watson mylesgw@gmail.com wrote:
On Sun, May 10, 2009 at 6:21 AM, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
It looks like the problem is that the memory you're reserving for VGA and the memory reserved for high tables ends up in the same place (ending at tomk.) If you decide which one should go at the end and modify the math, it should work.
i completely agree - there seems to be an overlapped memory region, but i couldn't trace it deep enough to be able to fix it. sorry... im not familiar enough with coreboot code. i suspect you guys will have better luck.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com Acked-by: Corey Osgood corey.osgood@gmail.com
Since it looks like an easy fix, let's get it right before committing it. It breaks SeaBIOS, and our assumption that HAVE_HIGH_TABLES doesn't break anything.
i'll keep an eye on HAVE_HIGH_TABLES patches and migrate them to my patches and check if it fix the issue. i'll update the ml as for the results.
Thanks, Myles
Elia.
Quick review below, I didn't yet find the time to test on hardware, will hopefully be able to do that today.
- val = 0;
- val = pci_read_config8(PCI_DEV(0, 0, 0), MISSC2);
The 'val = 0' should no be needed if you do pci_read_config8() right after that.
- val |= 0x06;
- val |= 0xc6;
Why this? Only the last line alone should also do?
+#ifdef CONFIG_VIDEO_MB
/* check for VGA reserved memory* possible CONFIG_VIDEO_MB values are 512(kb) and 1(mb)*/if (CONFIG_VIDEO_MB == 512) {tomk -= 512;printk_debug("Allocating 512KB of RAM for VGA\n");} else if (CONFIG_VIDEO_MB == 1) {tomk -= 1024 ;printk_debug("Allocating 1MB of RAM for VGA\n");
} else {/* assume no vga if incorrect value */tomk == tomk;
Isn't this is no-op? Or am I missing something?
Uwe.
+#ifdef CONFIG_VIDEO_MB
/* check for VGA reserved memory* possible CONFIG_VIDEO_MB values are 512(kb) and 1(mb)*/if (CONFIG_VIDEO_MB == 512) {tomk -= 512;printk_debug("Allocating 512KB of RAM for VGA\n");} else if (CONFIG_VIDEO_MB == 1) {tomk -= 1024 ;printk_debug("Allocating 1MB of RAM for VGA\n");
} else {/* assume no vga if incorrect value */tomk == tomk;Isn't this is no-op? Or am I missing something?
I don't know what you mean no-op? Are you taking about the "#ifdef CONFIG_VIDEO_MB", because I don't think that is necessary. This came from the i830, but I don't use "#ifdef CONFIG_VIDEO_MB" and it works fine. Intel onboard "shared" graphics memory is always just below TOM.
On Tue, May 12, 2009 at 8:12 AM, Joseph Smith joe@settoplinux.org wrote:
+#ifdef CONFIG_VIDEO_MB
- /* check for VGA reserved memory
- * possible CONFIG_VIDEO_MB values are 512(kb) and 1(mb)
- */
- if (CONFIG_VIDEO_MB == 512) {
- tomk -= 512;
- printk_debug("Allocating 512KB of RAM for VGA\n");
- } else if (CONFIG_VIDEO_MB == 1) {
- tomk -= 1024 ;
- printk_debug("Allocating 1MB of RAM for VGA\n");
- } else {
- /* assume no vga if incorrect value */
- tomk == tomk;
Isn't this is no-op? Or am I missing something?
I don't know what you mean no-op?
tomk==tomk doesn't do anything. It would probably be better to leave out that else branch.
Are you taking about the "#ifdef CONFIG_VIDEO_MB", because I don't think that is necessary.
It should be #if CONFIG_VIDEO_MB >0 if we use it. We don't use #ifdef in v2 because the options are always defined if they are used.
Thanks, Myles
On Tue, 12 May 2009 08:18:20 -0600, Myles Watson mylesgw@gmail.com wrote:
On Tue, May 12, 2009 at 8:12 AM, Joseph Smith joe@settoplinux.org
wrote:
+#ifdef CONFIG_VIDEO_MB
- /* check for VGA reserved memory
- * possible CONFIG_VIDEO_MB values are 512(kb) and
1(mb)
- */
- if (CONFIG_VIDEO_MB == 512) {
- tomk -= 512;
- printk_debug("Allocating 512KB of RAM
for VGA\n");
- } else if (CONFIG_VIDEO_MB == 1) {
- tomk -= 1024 ;
- printk_debug("Allocating 1MB of RAM for
VGA\n");
- } else {
- /* assume no vga if incorrect value */
- tomk == tomk;
Isn't this is no-op? Or am I missing something?
I don't know what you mean no-op?
tomk==tomk doesn't do anything. It would probably be better to leave out that else branch.
Ahh, I have to disagree. For example, what if someone puts a value of 4 (CONFIG_VIDEO_MB = 4) in by mistake. It will cause coreboot to crash because it will not know what to do with that value...
The else tomk == tomk is more of a safety net than anything.
So if you keep the else and someone puts a value of 4 (CONFIG_VIDEO_MB = 4) in by mistake, coreboot will still boot, and worse case scenario you just won't have vga.
On Tue, 12 May 2009 11:05:59 -0400, Joseph Smith joe@settoplinux.org wrote:
On Tue, 12 May 2009 08:18:20 -0600, Myles Watson mylesgw@gmail.com wrote:
On Tue, May 12, 2009 at 8:12 AM, Joseph Smith joe@settoplinux.org
wrote:
+#ifdef CONFIG_VIDEO_MB
- /* check for VGA reserved memory
- * possible CONFIG_VIDEO_MB values are 512(kb) and
1(mb)
- */
- if (CONFIG_VIDEO_MB == 512) {
- tomk -= 512;
- printk_debug("Allocating 512KB of RAM
for VGA\n");
- } else if (CONFIG_VIDEO_MB == 1) {
- tomk -= 1024 ;
- printk_debug("Allocating 1MB of RAM
for
VGA\n");
- } else {
- /* assume no vga if incorrect value */
- tomk == tomk;
Isn't this is no-op? Or am I missing something?
I don't know what you mean no-op?
tomk==tomk doesn't do anything. It would probably be better to leave out that else branch.
Ahh, I have to disagree. For example, what if someone puts a value of 4 (CONFIG_VIDEO_MB = 4) in by mistake. It will cause coreboot to crash because it will not know what to do with that value...
The else tomk == tomk is more of a safety net than anything.
So if you keep the else and someone puts a value of 4 (CONFIG_VIDEO_MB = 4) in by mistake, coreboot will still boot, and worse case scenario you just won't have vga.
Or maybe a switch would be better with tomk == tomk as the default.
Ok, I get your point Myles.
I did do it a little different on the i830. I just added an extra variable so if CONFIG_VIDEO_MB is 0 it doesn't really do anything. Then it subtracts from tomk afterwards, like this:
int igd_memory = 0;
if (CONFIG_VIDEO_MB == 512) { igd_memory = (CONFIG_VIDEO_MB); } else { igd_memory = (CONFIG_VIDEO_MB * 1024); }
tomk -= igd_memory;
Elia I think this would work nicely for you.
int igd_memory = 0;
if (CONFIG_VIDEO_MB == 512) { igd_memory = (CONFIG_VIDEO_MB); } else { igd_memory = (CONFIG_VIDEO_MB * 1024); }
If you made the 512(K) 0.5 (MB), then you wouldn't need the if.
tomk -= (CONFIG_VIDEO_MB * 1024);
I think CONFIG_VIDEO_MB=512 is misleading.
Thanks, Myles
On Tue, May 12, 2009 at 4:57 PM, Uwe Hermann uwe@hermann-uwe.de wrote:
Quick review below, I didn't yet find the time to test on hardware, will hopefully be able to do that today.
- val = 0;
- val = pci_read_config8(PCI_DEV(0, 0, 0), MISSC2);
The 'val = 0' should no be needed if you do pci_read_config8() right after that.
agreed. its just a leftover. the 'val=0' can be removed.
- val |= 0x06;
- val |= 0xc6;
Why this? Only the last line alone should also do?
same here - the 'val += 0x06' is a leftover from the original code. it can be removed.
+#ifdef CONFIG_VIDEO_MB
- /* check for VGA reserved memory
- * possible CONFIG_VIDEO_MB values are 512(kb) and 1(mb)
- */
- if (CONFIG_VIDEO_MB == 512) {
- tomk -= 512;
- printk_debug("Allocating 512KB of RAM for VGA\n");
- } else if (CONFIG_VIDEO_MB == 1) {
- tomk -= 1024 ;
- printk_debug("Allocating 1MB of RAM for VGA\n");
- } else {
- /* assume no vga if incorrect value */
- tomk == tomk;
Isn't this is no-op? Or am I missing something?
no, you're not missing a thing. i actually copied this from other northbridge code and i liked this no-op because its a cleaner code. from a programmer side of view, it is redundant...
Uwe.
http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
I hope you'll get a chance to play with the patch and maybe fix the HIGH_TABLE issue.
Blessings, Elia.
On Sun, 10 May 2009 15:21:52 +0300, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
Elia, any progress on the high tables stuff yet? It would be real shame to see this great code goto the way side. Maybe you could split the patch in two and we can get all the non high tables stuff commited to svn?
On Thu, May 21, 2009 at 10:03 PM, Joseph Smith joe@settoplinux.org wrote:
On Sun, 10 May 2009 15:21:52 +0300, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
Elia, any progress on the high tables stuff yet? It would be real shame to see this great code goto the way side. Maybe you could split the patch in two and we can get all the non high tables stuff commited to svn?
im still waiting for Uwe to try the patch - he has some issues with his hardware so we need to have patience. If this won't work out, then i'll do my best and trace the high-tables issue myself and update the list as for my findings.
as for splitting the patch - can be done, but i suggest we wait a bit and give Uwe a chance since he is the main 82810 coder and he has done wonders in the past so i suspect he'll do magic once more :-)
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
Elia.
On Fri, May 22, 2009 at 03:54:43AM +0300, Elia Yehuda wrote:
On Sun, 10 May 2009 15:21:52 +0300, Elia Yehuda z4ziggy@gmail.com wrote:
This patch enables the onboard VGA found on 82810 boards and fixes the memory procedures to support different kinds of DIMMs. also, support for 82810e board had been added. The only drawback from this patch is the HAVE_HIGH_TABLES being disabled since it disables (for unknown reason) the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
Elia, any progress on the high tables stuff yet? It would be real shame to see this great code goto the way side. Maybe you could split the patch in two and we can get all the non high tables stuff commited to svn?
im still waiting for Uwe to try the patch - he has some issues with his hardware so we need to have patience.
Yeah, sorry for the long delay. I had hardware issues, which I fixed by replacing some dead capacitors on my i810 board. I have successfully tested the (slightly modified for cosmetics) BUFF_SC parts of the patch, which works fine and is thus committed as r4338 (thanks!)
If this won't work out, then i'll do my best and trace the high-tables issue myself and update the list as for my findings.
as for splitting the patch - can be done, but i suggest we wait a bit and give Uwe a chance
In general I recommend to split patches into independent functional units indeed, that makes testing and reviewing a lot easier.
Haven't had much luck with the HIGH_TABLES stuff yet, need to look into it some more, will post the remainders of the patch (without the now-committed BUFF_SC parts) later and/or check what's going on with HIGH_TABLES...
Uwe.
On Fri, 5 Jun 2009 02:27:09 +0200, Uwe Hermann uwe@hermann-uwe.de wrote:
On Fri, May 22, 2009 at 03:54:43AM +0300, Elia Yehuda wrote:
On Sun, 10 May 2009 15:21:52 +0300, Elia Yehuda z4ziggy@gmail.com
wrote:
This patch enables the onboard VGA found on 82810 boards and fixes
the
memory procedures to support different kinds of DIMMs. also, support
for
82810e board had been added. The only drawback from this patch is
the
HAVE_HIGH_TABLES being disabled since it disables (for unknown
reason)
the onboard VGA.
Signed-off-by: Elia Yehuda z4ziggy@gmail.com
Elia, any progress on the high tables stuff yet? It would be real
shame to
see this great code goto the way side. Maybe you could split the patch
in
two and we can get all the non high tables stuff commited to svn?
im still waiting for Uwe to try the patch - he has some issues with his hardware so we need to have patience.
Yeah, sorry for the long delay. I had hardware issues, which I fixed by replacing some dead capacitors on my i810 board. I have successfully tested the (slightly modified for cosmetics) BUFF_SC parts of the patch, which works fine and is thus committed as r4338 (thanks!)
If this won't work out, then i'll do my best and trace the high-tables issue myself and update the list as for my findings.
as for splitting the patch - can be done, but i suggest we wait a bit
and
give Uwe a chance
In general I recommend to split patches into independent functional units indeed, that makes testing and reviewing a lot easier.
Haven't had much luck with the HIGH_TABLES stuff yet, need to look into it some more, will post the remainders of the patch (without the now-committed BUFF_SC parts) later and/or check what's going on with HIGH_TABLES...
Sweet thanks Uwe :-)
Hi,
On Fri, Jun 05, 2009 at 02:27:09AM +0200, Uwe Hermann wrote:
Haven't had much luck with the HIGH_TABLES stuff yet, need to look into it some more, will post the remainders of the patch (without the now-committed BUFF_SC parts) later and/or check what's going on with HIGH_TABLES...
OK, I've just committed (somewhat) working VGA support in r4398 for 82810 and 82810E and enabled it for my test board (MS-6178) in r4399.
http://www.coreboot.org/pipermail/coreboot/2009-July/050496.html http://www.coreboot.org/pipermail/coreboot/2009-July/050497.html
The VGA support is probably not perfect, yet, I'll do some more testing and fixing.
Please let me know if this also works on your 82810E board (it should) and/or if it needs additional patching.
So far I see no problems with enabled HIGH_TABLES, will try SeaBIOS soon, and also compare the logs of enabled/disabled HIGH_TABLES to make sure everything works fine.
Cheers, Uwe.
-
Corey Osgood -
Elia Yehuda -
Joseph Smith -
Myles Watson -
Uwe Hermann