Re: [coreboot] Supermicro H8QME-2+: Dumping smbus registers
Paul Menzel escribió: Dear Knut, Am Mittwoch, den 10.03.2010, 17:26 +0100 schrieb Knut Kujat: […] I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! is it possible to share that piece of code? […] Anyway, nice to hear you ar making some progress and good luck with the next steps! Thanks, Paul Hi, you can find the function at src/mainboard/supermicro/h8dme/romstage.c line 101: static void dump_smbus_registers(void). bye! Knut Kujat -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Un-brick a GAM57SLIS4
Hello, [if this is off-topic here, please feel free to ignore/delete this message] I accidently flashed my Gigabyte GA-M57-SLI-S4 Rev. 1 with a corrupted BIOS file. The board does not boot anymore, just a black screen, no beeps, simply dead. I would be glad if I could save the money for a new board so I've got the following question: If I do the hardware-mod as shown in http://private.vlsi.informatik.tu-darmstadt.de/st/ and can obtain a programmed flash rom with a valid BIOS inside, would it be possible to reanimate the board again? Would it be neccessary to remove the original Flash-BIOS or can leave it (permanently switched off) on the board? Thanks Thorsten -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] romcc segfaults; serious help needed
Keith Hui wrote:
I posted a new 440BX RAM init code a few days ago that was
segfaulting romcc, and I didn't get any response.
There aren't very many romcc ninjas.
void romcc_fail(void) {
int dimm03 = 0;
int dimm47 = 0;
char mbsc[5];
char mbfs[3];
This is already putting some pressure on register allocation. Can you
help romcc by making dimm03 and dimm47 into char also? Consistently
using unsigned may also help.
mbfs and mbsc are meant to be an array of bytes that make up the
MBFS and MBSC registers in the 440BX, to be written out to it once
they're all set.
Would it be possible to not store, and instead write out to registers
as soon as possible? This will also help romcc.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] romcc segfaults; serious help needed
Am 11.03.2010 04:25, schrieb Keith Hui:
Hi guys,
I posted a new 440BX RAM init code a few days ago that was segfaulting
romcc, and I didn't get any response.
In the meantime I have narrowed the cause to this code fragment, with
enough wrapper added so it can be fed to romcc on its own:
Thank you for the test case, I could reproduce the crash.
Attached patch fixes the romcc segfaults when using the |=, +=, ^=
operators on array fields and produces reasonably looking code.
I did some tests to verify that the behaviour didn't change, but your
test case compiles to no code (except some useless jmp instructions) as
it has no side effects, so I can only verify it builds.
Please test it on your real world code.
Signed-off-by: Patrick Georgi patrick.geo...@coresystems.de
Index: util/romcc/romcc.c
===
--- util/romcc/romcc.c (revision 5200)
+++ util/romcc/romcc.c (working copy)
@@ -1896,12 +1896,16 @@
return;
if (!user)
return;
- ptr = used-use;
- while(*ptr) {
- if ((*ptr)-member == user) {
- return;
+ if (used-use == (void*)-1)
+ used-use = 0;
+ if (used-use) {
+ ptr = used-use;
+ while(*ptr) {
+ if ((*ptr)-member == user) {
+ return;
+ }
+ ptr = (*ptr)-next;
}
- ptr = (*ptr)-next;
}
/* Append new to the head of the list,
* copy_func and rename_block_variables
@@ -11599,19 +11603,19 @@
}
def = write_expr(state, left,
triple(state, op, left-type,
- read_expr(state, left), right));
+ read_expr(state, copy_triple(state, left)),
right));
break;
case TOK_PLUSEQ:
lvalue(state, left);
eat(state, TOK_PLUSEQ);
def = write_expr(state, left,
- mk_add_expr(state, left, assignment_expr(state)));
+ mk_add_expr(state, copy_triple(state, left),
assignment_expr(state)));
break;
case TOK_MINUSEQ:
lvalue(state, left);
eat(state, TOK_MINUSEQ);
def = write_expr(state, left,
- mk_sub_expr(state, left, assignment_expr(state)));
+ mk_sub_expr(state, copy_triple(state, left),
assignment_expr(state)));
break;
case TOK_SLEQ:
case TOK_SREQ:
@@ -11635,7 +11639,7 @@
}
def = write_expr(state, left,
triple(state, op, left-type,
- read_expr(state, left), right));
+ read_expr(state, copy_triple(state,left)),
right));
break;
}
return def;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] romcc segfaults; serious help needed
void romcc_fail(void) {
int dimm03 = 0;
int dimm47 = 0;
char mbsc[5];
char mbfs[3];
This is already putting some pressure on register allocation. Can you
help romcc by making dimm03 and dimm47 into char also? Consistently
using unsigned may also help.
mbfs and mbsc are meant to be an array of bytes that make up the
MBFS and MBSC registers in the 440BX, to be written out to it once
they're all set.
Would it be possible to not store, and instead write out to registers
as soon as possible? This will also help romcc.
//Peter
I feel good being able to push romcc to the limit, and probably off the
cliff given what happened. :-P
Two of the MBSC bytes are common, at least for now. I'll try eliminating the
variables for them.
On further tries the problem seems to be with the use of |= operator on an
array item. Elsewhere in the original raminit code uses |= with a simple
variable and it doesn't seem to segfault.
But other than that, there are three conditions to check for, and the
registers cannot be finalized and written out until all three are done.
Thanks
Keith
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Strange corruption with printk
2) Add the
static void set_init_ram_access_uc(void)
{
set_var_mtrr(0, 0x, CONFIG_RAMTOP, MTRR_TYPE_UNCACHED);
}
And call the set_init_ram_access_uc instead of set_init_ram_access and
call
again set_init_ram_access after the copy.
I'll look at that too
That didn't make any difference for my symptoms, but I'm interested in why
you'd want to set it uncacheable.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Supermicro H8QME-2+ mct_d fatal exit.
On Wed, Mar 10, 2010 at 05:26:47PM +0100, Knut Kujat wrote: I finally know that my issue must be related with the smbus registers because on a vendor bios running machine and using i2cdetect and i2cdump I get several values for different i2c devices detected, I get the same values when I successfully start with coreboot. But when I start with coreboot and fail with mcr_d fatal exit those registers are blank, I know that because I found a nice piece of code dumping smbus registers on the h8dme board :D thx to the autor!! That would have been Marc Jones :) Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Join us in Cambridge for LibrePlanet, March 19th-21st! http://groups.fsf.org/wiki/LibrePlanet2010 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [PATCH] use memset
I was having trouble with stack corruption. Using memset (C) instead of
clear_memory(asm) speeds it up by almost a factor of 2 for a 1M region.
TSC difference with clear_memory 0xFA884D
TSC difference with memset 0x826742
Anyway, this patch removes a couple of files that don't need to exist
anymore, given that only K8 was using clear_memory.
SIgned-off-by: Myles Watson myle...@gmail.com
Thanks,
Myles
Index: svn/src/cpu/amd/car/clear_init_ram.c
===
--- svn.orig/src/cpu/amd/car/clear_init_ram.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/* by yhlu 6.2005 */
-/* be warned, this file will be used core 0/node 0 only */
-
-static void __attribute__((noinline)) clear_init_ram(void)
-{
- // gcc 3.4.5 will inline the copy_and_run and clear_init_ram in post_cache_as_ram
- // will reuse %edi as 0 from clear_memory for copy_and_run part, actually it is increased already
- // so noline clear_init_ram
-
-#if CONFIG_HAVE_ACPI_RESUME == 1
- /* clear only coreboot used region of memory. Note: this may break ECC enabled boards */
- clear_memory( CONFIG_RAMBASE, (CONFIG_RAMTOP) - CONFIG_RAMBASE - CONFIG_DCACHE_RAM_SIZE);
-#else
-clear_memory(0, ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE));
-#endif
-}
-
-/* be warned, this file will be used by core other than core 0/node 0 or core0/node0 when cpu_reset*/
-static void set_init_ram_access(void)
-{
- set_var_mtrr(0, 0x, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
-}
Index: svn/src/cpu/amd/car/post_cache_as_ram.c
===
--- svn.orig/src/cpu/amd/car/post_cache_as_ram.c
+++ svn/src/cpu/amd/car/post_cache_as_ram.c
@@ -3,8 +3,6 @@
*/
#include cpu/amd/car/disable_cache_as_ram.c
-#include cpu/amd/car/clear_init_ram.c
-
static inline void print_debug_pcar(const char *strval, uint32_t val)
{
printk_debug(%s%08x\r\n, strval, val);
@@ -64,7 +62,8 @@ static void post_cache_as_ram(void)
#error You need to set CONFIG_RAMTOP greater than 1M
#endif
- set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP) */
+ /* So we can access RAM from [1M, CONFIG_RAMTOP) */
+ set_var_mtrr(0, 0x, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
// dump_mem(CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x8000, CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x7c00);
print_debug(Copying data from cache to RAM -- switching to use RAM as stack... );
@@ -94,7 +93,12 @@ static void post_cache_as_ram(void)
disable_cache_as_ram_bsp();
print_debug(Clearing initial memory region: );
-clear_init_ram(); //except the range from [(CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE, (CONFIG_RAMTOP))
+#if CONFIG_HAVE_ACPI_RESUME == 1
+ /* clear only coreboot used region of memory. Note: this may break ECC enabled boards */
+ memset((void*) CONFIG_RAMBASE, (CONFIG_RAMTOP) - CONFIG_RAMBASE - CONFIG_DCACHE_RAM_SIZE, 0);
+#else
+memset((void*)0, ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE), 0);
+#endif
print_debug(Done\r\n);
// dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);
Index: svn/src/cpu/amd/model_10xxx/model_10xxx_init.c
===
--- svn.orig/src/cpu/amd/model_10xxx/model_10xxx_init.c
+++ svn/src/cpu/amd/model_10xxx/model_10xxx_init.c
@@ -34,7 +34,6 @@
#include cpu/cpu.h
#include cpu/x86/cache.h
#include cpu/x86/mtrr.h
-#include cpu/x86/mem.h
#include cpu/amd/quadcore.h
#include cpu/amd/model_10xxx_msr.h
Index: svn/src/cpu/amd/model_fxx/model_fxx_init.c
===
--- svn.orig/src/cpu/amd/model_fxx/model_fxx_init.c
+++ svn/src/cpu/amd/model_fxx/model_fxx_init.c
@@ -24,7 +24,6 @@
#include cpu/cpu.h
#include cpu/x86/cache.h
#include cpu/x86/mtrr.h
-#include cpu/x86/mem.h
#include cpu/amd/dualcore.h
@@ -238,7 +237,7 @@ static inline void clear_2M_ram(unsigned
/* clear memory 2M (limitk - basek) */
addr = (void *)(((uint32_t)addr) | ((basek 0x7ff) 10));
-clear_memory(addr, size);
+memset(addr, size, 0);
}
static void init_ecc_memory(unsigned node_id)
Index: svn/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
===
--- svn.orig/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
+++ svn/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
@@ -130,7 +130,6 @@ static int spd_read_byte(u32 device, u32
#include northbridge/amd/amdfam10/amdfam10.h
#include northbridge/amd/amdht/ht_wrapper.c
-#include include/cpu/x86/mem.h
#include northbridge/amd/amdfam10/raminit_sysinfo_in_ram.c
#include northbridge/amd/amdfam10/raminit_amdmct.c
#include northbridge/amd/amdfam10/amdfam10_pci.c
Index: svn/src/mainboard/msi/ms9652_fam10/romstage.c
===
--- svn.orig/src/mainboard/msi/ms9652_fam10/romstage.c
Re: [coreboot] [PATCH] use memset
Am 11.03.2010 22:14, schrieb Myles Watson: I was having trouble with stack corruption. Using memset (C) instead of clear_memory(asm) speeds it up by almost a factor of 2 for a 1M region. TSC difference with clear_memory 0xFA884D TSC difference with memset 0x826742 Interesting that the C version is faster in this case. Anyway, this patch removes a couple of files that don't need to exist anymore, given that only K8 was using clear_memory. Yay :-) SIgned-off-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com Acked-by: Patrick Georgi patrick.geo...@coresystems.de -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5201 - in trunk/src: cpu/amd/car cpu/amd/model_10xxx cpu/amd/model_fxx include/cpu/x86 mainboard/amd/serengeti_cheetah_fam10 mainboard/msi/ms9652_fam10 mainboard/supermicro/h8dmr_
Author: myles
Date: Thu Mar 11 22:34:27 2010
New Revision: 5201
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5201
Log:
Replace clear_memory with memset.
Replace set_init_ram_access with the call to set_var_mtrr.
Remove unused #include statments.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Patrick Georgi patrick.geo...@coresystems.de
Deleted:
trunk/src/cpu/amd/car/clear_init_ram.c
trunk/src/include/cpu/x86/mem.h
Modified:
trunk/src/cpu/amd/car/post_cache_as_ram.c
trunk/src/cpu/amd/model_10xxx/init_cpus.c
trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c
trunk/src/cpu/amd/model_fxx/init_cpus.c
trunk/src/cpu/amd/model_fxx/model_fxx_init.c
trunk/src/mainboard/amd/serengeti_cheetah_fam10/romstage.c
trunk/src/mainboard/msi/ms9652_fam10/romstage.c
trunk/src/mainboard/supermicro/h8dmr_fam10/romstage.c
trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c
trunk/src/mainboard/tyan/s2912_fam10/romstage.c
trunk/src/northbridge/amd/amdk8/raminit.c
trunk/src/northbridge/amd/amdk8/raminit_f.c
trunk/src/northbridge/intel/e7520/raminit.c
trunk/src/northbridge/intel/e7525/raminit.c
trunk/src/northbridge/intel/i3100/raminit.c
trunk/src/northbridge/intel/i3100/raminit_ep80579.c
trunk/src/northbridge/intel/i945/raminit.c
Modified: trunk/src/cpu/amd/car/post_cache_as_ram.c
==
--- trunk/src/cpu/amd/car/post_cache_as_ram.c Wed Mar 10 04:43:05 2010
(r5200)
+++ trunk/src/cpu/amd/car/post_cache_as_ram.c Thu Mar 11 22:34:27 2010
(r5201)
@@ -3,8 +3,6 @@
*/
#include cpu/amd/car/disable_cache_as_ram.c
-#include cpu/amd/car/clear_init_ram.c
-
static inline void print_debug_pcar(const char *strval, uint32_t val)
{
printk_debug(%s%08x\r\n, strval, val);
@@ -64,7 +62,8 @@
#error You need to set CONFIG_RAMTOP greater than 1M
#endif
- set_init_ram_access(); /* So we can access RAM from [1M, CONFIG_RAMTOP)
*/
+ /* So we can access RAM from [1M, CONFIG_RAMTOP) */
+ set_var_mtrr(0, 0x, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
// dump_mem(CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x8000,
CONFIG_DCACHE_RAM_BASE+CONFIG_DCACHE_RAM_SIZE-0x7c00);
print_debug(Copying data from cache to RAM -- switching to use RAM as
stack... );
@@ -94,7 +93,12 @@
disable_cache_as_ram_bsp();
print_debug(Clearing initial memory region: );
-clear_init_ram(); //except the range from [(CONFIG_RAMTOP) -
CONFIG_DCACHE_RAM_SIZE, (CONFIG_RAMTOP))
+#if CONFIG_HAVE_ACPI_RESUME == 1
+ /* clear only coreboot used region of memory. Note: this may break ECC
enabled boards */
+ memset((void*) CONFIG_RAMBASE, (CONFIG_RAMTOP) - CONFIG_RAMBASE -
CONFIG_DCACHE_RAM_SIZE, 0);
+#else
+memset((void*)0, ((CONFIG_RAMTOP) - CONFIG_DCACHE_RAM_SIZE), 0);
+#endif
print_debug(Done\r\n);
// dump_mem((CONFIG_RAMTOP) - 0x8000, (CONFIG_RAMTOP) - 0x7c00);
Modified: trunk/src/cpu/amd/model_10xxx/init_cpus.c
==
--- trunk/src/cpu/amd/model_10xxx/init_cpus.c Wed Mar 10 04:43:05 2010
(r5200)
+++ trunk/src/cpu/amd/model_10xxx/init_cpus.c Thu Mar 11 22:34:27 2010
(r5201)
@@ -421,7 +421,7 @@
*/
//wait_till_sysinfo_in_ram();
- set_init_ram_access();
+ set_var_mtrr(0, 0x, CONFIG_RAMTOP, MTRR_TYPE_WRBACK);
STOP_CAR_AND_CPU();
printk_debug(\nAP %02x should be halted but you are reading
this\n, apicid);
Modified: trunk/src/cpu/amd/model_10xxx/model_10xxx_init.c
==
--- trunk/src/cpu/amd/model_10xxx/model_10xxx_init.cWed Mar 10 04:43:05
2010(r5200)
+++ trunk/src/cpu/amd/model_10xxx/model_10xxx_init.cThu Mar 11 22:34:27
2010(r5201)
@@ -34,7 +34,6 @@
#include cpu/cpu.h
#include cpu/x86/cache.h
#include cpu/x86/mtrr.h
-#include cpu/x86/mem.h
#include cpu/amd/quadcore.h
#include cpu/amd/model_10xxx_msr.h
Modified: trunk/src/cpu/amd/model_fxx/init_cpus.c
==
--- trunk/src/cpu/amd/model_fxx/init_cpus.c Wed Mar 10 04:43:05 2010
(r5200)
+++ trunk/src/cpu/amd/model_fxx/init_cpus.c Thu Mar 11 22:34:27 2010
(r5201)
@@ -317,7 +317,7 @@
print_initcpu8(while waiting for BSP signal to
STOP, timeout in ap , apicid);
}
lapic_write(LAPIC_MSG_REG, (apicid24) | 0x44); //
bsp can not check it before stop_this_cpu
-set_init_ram_access();
+ set_var_mtrr(0, 0x, CONFIG_RAMTOP,
MTRR_TYPE_WRBACK);
#if CONFIG_MEM_TRAIN_SEQ == 1
Re: [coreboot] [PATCH] use memset
Am 11.03.2010 22:14, schrieb Myles Watson: I was having trouble with stack corruption. Using memset (C) instead of clear_memory(asm) speeds it up by almost a factor of 2 for a 1M region. I should have said it got rid of the memory corruption I was seeing, too :) TSC difference with clear_memory 0xFA884D TSC difference with memset 0x826742 Interesting that the C version is faster in this case. Yeah. Maybe you could do a lot better with a different asm implementation. You'd hope that the compiler would have a pretty good routine for clearing memory, though. I didn't dig into it to see what the real difference was. SIgned-off-by: Myles Watson myle...@gmail.com mailto:myle...@gmail.com Acked-by: Patrick Georgi patrick.geo...@coresystems.de Rev 5201. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] [commit] r5202 - trunk/src/cpu/amd/car
Author: myles
Date: Thu Mar 11 23:12:10 2010
New Revision: 5202
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5202
Log:
Replace spaces with tabs. Trivial.
Signed-off-by: Myles Watson myle...@gmail.com
Acked-by: Myles Watson myle...@gmail.com
Modified:
trunk/src/cpu/amd/car/cache_as_ram.inc
trunk/src/cpu/amd/car/disable_cache_as_ram.c
trunk/src/cpu/amd/car/post_cache_as_ram.c
Modified: trunk/src/cpu/amd/car/cache_as_ram.inc
==
--- trunk/src/cpu/amd/car/cache_as_ram.inc Thu Mar 11 22:34:27 2010
(r5201)
+++ trunk/src/cpu/amd/car/cache_as_ram.inc Thu Mar 11 23:12:10 2010
(r5202)
@@ -270,8 +270,8 @@
#else
#define REAL_XIP_ROM_BASE CONFIG_XIP_ROM_BASE
#endif
- movl$REAL_XIP_ROM_BASE, %eax
- orl $MTRR_TYPE_WRBACK, %eax
+ movl$REAL_XIP_ROM_BASE, %eax
+ orl $MTRR_TYPE_WRBACK, %eax
wrmsr
movl$0x203, %ecx
Modified: trunk/src/cpu/amd/car/disable_cache_as_ram.c
==
--- trunk/src/cpu/amd/car/disable_cache_as_ram.cThu Mar 11 22:34:27
2010(r5201)
+++ trunk/src/cpu/amd/car/disable_cache_as_ram.cThu Mar 11 23:12:10
2010(r5202)
@@ -2,45 +2,45 @@
/* be warned, this file will be used other cores and core 0 / node 0 */
static inline __attribute__((always_inline)) void disable_cache_as_ram(void)
{
-__asm__ __volatile__ (
-/* We don't need cache as ram for now on */
-/* disable cache */
-movl%%cr0, %%eax\n\t
-orl$(0x130),%%eax\n\t
-movl%%eax, %%cr0\n\t
+ __asm__ __volatile__ (
+ /* We don't need cache as ram for now on */
+ /* disable cache */
+ movl%%cr0, %%eax\n\t
+ orl$(0x130),%%eax\n\t
+ movl%%eax, %%cr0\n\t
-/* clear sth */
-movl$0x269, %%ecx\n\t /* fix4k_c8000*/
-xorl%%edx, %%edx\n\t
-xorl%%eax, %%eax\n\t
+ /* clear sth */
+ movl$0x269, %%ecx\n\t /* fix4k_c8000*/
+ xorl%%edx, %%edx\n\t
+ xorl%%eax, %%eax\n\t
wrmsr\n\t
#if CONFIG_DCACHE_RAM_SIZE 0x8000
movl$0x268, %%ecx\n\t /* fix4k_c*/
-wrmsr\n\t
+ wrmsr\n\t
#endif
-/* disable fixed mtrr from now on, it will be enabled by coreboot_ram
again*/
-movl$0xC0010010, %%ecx\n\t
-//movl$SYSCFG_MSR, %ecx\n\t
-rdmsr\n\t
-andl$(~(318)), %%eax\n\t
-//andl$(~(SYSCFG_MSR_MtrrFixDramModEn |
SYSCFG_MSR_MtrrFixDramEn)), %eax\n\t
-wrmsr\n\t
+ /* disable fixed mtrr from now on, it will be enabled by coreboot_ram
again*/
+ movl$0xC0010010, %%ecx\n\t
+// movl$SYSCFG_MSR, %ecx\n\t
+ rdmsr\n\t
+ andl$(~(318)), %%eax\n\t
+// andl$(~(SYSCFG_MSR_MtrrFixDramModEn | SYSCFG_MSR_MtrrFixDramEn)),
%eax\n\t
+ wrmsr\n\t
-/* Set the default memory type and disable fixed and enable variable
MTRRs */
-movl$0x2ff, %%ecx\n\t
-//movl$MTRRdefType_MSR, %ecx\n\t
-xorl%%edx, %%edx\n\t
-/* Enable Variable and Disable Fixed MTRRs */
-movl$0x0800, %%eax\n\t
-wrmsr\n\t
+ /* Set the default memory type and disable fixed and enable variable
MTRRs */
+ movl$0x2ff, %%ecx\n\t
+// movl$MTRRdefType_MSR, %ecx\n\t
+ xorl%%edx, %%edx\n\t
+ /* Enable Variable and Disable Fixed MTRRs */
+ movl$0x0800, %%eax\n\t
+ wrmsr\n\t
-/* enable cache */
-movl%%cr0, %%eax\n\t
-andl$0x9fff,%%eax\n\t
-movl%%eax, %%cr0\n\t
-::: memory, eax, ecx, edx
-);
+ /* enable cache */
+ movl%%cr0, %%eax\n\t
+ andl$0x9fff,%%eax\n\t
+ movl%%eax, %%cr0\n\t
+ ::: memory, eax, ecx, edx
+ );
}
static void disable_cache_as_ram_bsp(void)
Modified: trunk/src/cpu/amd/car/post_cache_as_ram.c
==
--- trunk/src/cpu/amd/car/post_cache_as_ram.c Thu Mar 11 22:34:27 2010
(r5201)
+++ trunk/src/cpu/amd/car/post_cache_as_ram.c Thu Mar 11 23:12:10 2010
(r5202)
@@ -5,7 +5,7 @@
static inline void print_debug_pcar(const char *strval, uint32_t val)
{
-printk_debug(%s%08x\r\n, strval, val);
+ printk_debug(%s%08x\r\n, strval, val);
}
/* from linux kernel 2.6.32 asm/string_32.h */
@@ -41,15 +41,15 @@
{
#if 1
-{
-/* Check value of esp to verify if we have enough rom for stack in
Cache as RAM */
-unsigned v_esp;
-__asm__ volatile (
-movl %%esp, %0\n\t
-: =a (v_esp)
-);
-print_debug_pcar(v_esp=, v_esp);
-}
+ {
+ /* Check value of esp to verify if we
Re: [coreboot] [PATCH] sb600: new way to load initial verb
Could it be a GSOC project?
1. Make an application to dump the codec structure and initial pin
configuration.
2. In Coreboot repository, add a public code to load initial pin
configuration as a CBFS modules.
Is it too small? I kinda don't have much time to do this.
Zheng
-Original Message-
From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org]
On Behalf Of Bao, Zheng
Sent: Tuesday, March 09, 2010 11:02 AM
To: coreboot@coreboot.org
Subject: Re: [coreboot] [PATCH] sb600: new way to load initial verb
-Original Message-
From: Carl-Daniel Hailfinger
[mailto:c-d.hailfinger.devel.2...@gmx.net]
Sent: Monday, March 08, 2010 10:15 PM
To: Bao, Zheng
Cc: Stefan Reinauer; coreboot@coreboot.org
Subject: Re: [coreboot] [PATCH] sb600: new way to load initial verb
On 08.03.2010 09:20, Bao, Zheng wrote:
The original way to load initial verb is quite inflexible.
The format of the command is:
CAd 31:28 - codec address
NID 27:20 - Nid
Verb 19:0 - Verb data
Each Nid has 4 byte data to write. It has to write one at a time.
0x01471c10, //1st byte 10
0x01471d40, //2nd byte 40
0x01471e01, //3rd byte 01
0x01471f01, //4th byte 01
The new code in sb600_hda.c and the code structure are quite
preliminary. When it is almost done and can satisfy everybody, We
can
define the pin configuration code at mainboard.
It would be cool if all chipsets could use the new verb
implementation.
#define CODEC_PIN_CONFIG_FILE codec/alc_882.h
or
config CODEC_PIN_CONFIG_FILE
string
default codec/alc_882.h
depends on BOARD_AMD_DBM690T
Or we define that file as separate uncompressed CBFS file.
Now I am wondering if it is legal provide the intial pin
configuration
code in coreboot. If it is legal, how can we get it? The 882 code
is
got from CIM.
Sorry, what is CIM?
In theory, the pin configuration is mainboard specific. If that is
true,
the pin configuration is similar to IRQ routing: There is usually
only
one correct and working solution. So it is possible that the
mainboard
vendor and the codec vendor own parts of it. Not sure. We could tell
users to dump verbs from their mainboards (is that possible?) and
add
the resulting file to CBFS.
It is mainboard specific. Each codec also has its own code. The
mainboard code is based on the codec code, I think. Dumping verbs is
possible. It needs a lot of work from the ground up. There are some
similar tools like http://helllabs.org/codecgraph/. Integrating them
to
coreboot/util needs permission, doesn't it?
Signed-off-by: Zheng Bao zheng@amd.com
Index: src/codec/alc_882.h
===
--- src/codec/alc_882.h (revision 0)
+++ src/codec/alc_882.h (revision 0)
@@ -0,0 +1,12 @@
struct _pin_config_codec_entry pin_config_file[] = {
+ {0x14, 0x01014010},
+ {0x15, 0x01011012},
+ {0x16, 0x01016011},
+ {0x17, 0x01012014},
+ {0x18, 0x01A19030},
+ {0x19, 0x41F0},
+ {0x1a, 0x01813080},
+ {0x1b, 0x41F0},
+ {0x1C, 0x41F0},
+ {0x1d, 0x41F0},
+ {0x1e, 0x01441150},
+ {0x1f, 0x01C46160},
{-1, -1}
};
Index: src/southbridge/amd/sb600/sb600_hda.c
===
--- src/southbridge/amd/sb600/sb600_hda.c (revision 5195)
+++ src/southbridge/amd/sb600/sb600_hda.c (working copy)
@@ -90,68 +90,19 @@
return 0;
}
-static u32 cim_verb_data[] = {
- 0x01471c10,
- 0x01471d40,
- 0x01471e01,
- 0x01471f01,
-/* 1 */
- 0x01571c12,
- 0x01571d10,
- 0x01571e01,
- 0x01571f01,
-/* 2 */
- 0x01671c11,
- 0x01671d60,
- 0x01671e01,
- 0x01671f01,
-/* 3 */
- 0x01771c14,
- 0x01771d20,
- 0x01771e01,
- 0x01771f01,
-/* 4 */
- 0x01871c30,
- 0x01871d90,
- 0x01871ea1,
- 0x01871f01,
-/* 5 */
- 0x01971cf0,
- 0x01971d11,
- 0x01971e11,
- 0x01971f41,
-/* 6 */
- 0x01a71c80,
- 0x01a71d30,
- 0x01a71e81,
- 0x01a71f01,
-/* 7 */
- 0x01b71cf0,
- 0x01b71d11,
- 0x01b71e11,
- 0x01b71f41,
-/* 8 */
- 0x01c71cf0,
- 0x01c71d11,
- 0x01c71e11,
- 0x01c71f41,
-/* 9 */
- 0x01d71cf0,
- 0x01d71d11,
- 0x01d71e11,
- 0x01d71f41,
-/* 10 */
- 0x01e71c50,
- 0x01e71d11,
- 0x01e71e44,
- 0x01e71f01,
-/* 11 */
- 0x01f71c60,
- 0x01f71d61,
- 0x01f71ec4,
- 0x01f71f01,
+typedef struct _pin_config_codec_entry {
Can you please kill the typedef and use struct
_pin_config_codec_entry
instead?
+ u8 nid;
+ u32 pin_config;
+} pin_config_codec_entry;
+
+static pin_config_codec_entry pin_config_file[] = {
+#ifdef CODEC_PIN_CONFIG_FILE
+ #include CODEC_PIN_CONFIG_FILE
Including C source makes code difficult to read. Can you move
[coreboot] [PATCH] New config option for 440BX northbridge
Hi all, This patch adds a Kconfig option for 440BX that enable compiling in the proper value for the SDRAMPWR bit in SDRAMC register for 3 or 4 DIMM slots. No more hard coding for 4 DIMM slots. Also sets it to be permanently enabled for a few ASUS boards (P2B-LS/D/DS, P3B-F) that I know for sure have 4 slots. This option only appears when Expert mode is selected in Kconfig. The actual code in raminit.c is still being boot tested and would have to wait until it boots all the way on my board. This just adds the config option so it is there when the code is ready. Cheers. Signed-off-by: Keith Hui buu...@gmail.com sdrampwrcfg.patch Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Un-brick a GAM57SLIS4
Hi Thorsten, On Thu, Mar 11, 2010 at 12:47:12AM +0100, tho@gmx.de wrote: [if this is off-topic here, please feel free to ignore/delete this message] I accidently flashed my Gigabyte GA-M57-SLI-S4 Rev. 1 with a corrupted BIOS file. The board does not boot anymore, just a black screen, no beeps, simply dead. I would be glad if I could save the money for a new board so I've got the following question: If I do the hardware-mod as shown in http://private.vlsi.informatik.tu-darmstadt.de/st/ and can obtain a programmed flash rom with a valid BIOS inside, would it be possible to reanimate the board again? Would it be neccessary to remove the original Flash-BIOS or can leave it (permanently switched off) on the board? If you do that modification, you'll have a switch or jumper to toggle between your 2 chips. If the second one has a good image, this should work. Thanks, Ward. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator Join us in Cambridge for LibrePlanet, March 19th-21st! http://groups.fsf.org/wiki/LibrePlanet2010 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] SeaBIOS support for high-speed (EHCI) USB
Hi, The latest SeaBIOS git now has support for EHCI USB controllers. This is in addition to the UHCI and OHCI support already in SeaBIOS. To obtain SeaBIOS, see: http://seabios.org/Download I've tested the EHCI support on my epia-cn. Booting from USB drives is now noticeably faster. Currently SeaBIOS supports USB keyboards, USB hubs, and USB drives. Help with testing on a wider range of hardware would be appreciated. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SeaBIOS support for high-speed (EHCI) USB
On 03/11/2010 09:30 PM, Kevin O'Connor wrote: Hi, The latest SeaBIOS git now has support for EHCI USB controllers. This is in addition to the UHCI and OHCI support already in SeaBIOS. To obtain SeaBIOS, see: http://seabios.org/Download I've tested the EHCI support on my epia-cn. Booting from USB drives is now noticeably faster. Currently SeaBIOS supports USB keyboards, USB hubs, and USB drives. Help with testing on a wider range of hardware would be appreciated. YAHOO! Great work Kevin! -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
