Re: k8 and memory training

On 31.08.2008 08:46, ron minnich wrote:
> see http://coreboot.pastebin.com/m354e6401
>
> I can't really tell if it's working.
>   

I looked at the log and we're clearly doing something wrong odd. The
execution order simply does not make that much sense.

arch/x86/stage1.c:stage1_main()
{
  //stuff
  global_vars_init();
  hardware_stage1();
  uart_init();  // initialize serial port
  /* Exactly from now on we can use printk to the serial port.
   * Celebrate this by printing a LB banner.
   */
  console_init();
  //more stuff
}

mainboard/amd/serengeti/stage1.c:hardware_stage1()
{
  printk(BIOS_ERR, "Stage1: enable rom ...\n");
  max = ARRAY_SIZE(register_values);
  setup_resource_map(register_values, max);
  enumerate_ht_chain();
  amd8111_enable_rom();
  printk(BIOS_ERR, "Done.\n");

Epia-CN Patch

This patch gets the Epia-CN working without ACPI or APIC.

All devices work, no irq storms. Enjoy.

Signed-off-by: Bari Ari <bari <at> onelabs.com>

--
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

r3556 - in trunk/coreboot-v2: src/mainboard/via/epia-cn src/northbridge/via/cn700 src/southbridge/via/vt8237r targets/via/epia-cn

Author: stuge
Date: 2008-09-01 03:48:07 +0200 (Mon, 01 Sep 2008)
New Revision: 3556

Modified:
   trunk/coreboot-v2/src/mainboard/via/epia-cn/Config.lb
   trunk/coreboot-v2/src/mainboard/via/epia-cn/Options.lb
   trunk/coreboot-v2/src/mainboard/via/epia-cn/auto.c
   trunk/coreboot-v2/src/northbridge/via/cn700/raminit.c
   trunk/coreboot-v2/src/northbridge/via/cn700/vga.c
   trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.c
   trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_lpc.c
   trunk/coreboot-v2/targets/via/epia-cn/Config.lb
Log:
This patch gets the Epia-CN working without ACPI or APIC.

All devices work, no irq storms. Enjoy.

Signed-off-by: Bari Ari <bari <at> onelabs.com>
Acked-by: Peter Stuge <peter <at> stuge.se>

Modified: trunk/coreboot-v2/src/mainboard/via/epia-cn/Config.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-cn/Config.lb	2008-08-31 22:10:35 UTC (rev 3555)
+++ trunk/coreboot-v2/src/mainboard/via/epia-cn/Config.lb	2008-09-01 01:48:07 UTC (rev 3556)
@@ -98,12 +98,14 @@
       register "ide0_80pin_cable" = "0"
       register "ide1_80pin_cable" = "0"
       device pci f.0 on end			# IDE
-      register "fn_ctrl_lo" = "0x8a"

Re: Epia-CN Patch

bari wrote:
> This patch gets the Epia-CN working without ACPI or APIC.
> 
> All devices work, no irq storms. Enjoy.
> 
> Signed-off-by: Bari Ari <bari <at> onelabs.com>

Awesome! Thank you very much.

I made some small changes regarding documentation and whitespace and
then committed this. It's in r3556.

//Peter

--
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

K8 INIT detection

Hi Marc,

I'm working on v3 and K8 setup. Right now, we try to determine whether
we rebooted because of INIT by looking at bit 11 of MTRRdefType because
it survives INIT and doesn't survive a cold or warm reboot. Although
this is a nice generic way, we can only read it early in stage0 asm
because we clobber it late in stage0 asm.

HyperTransport Initialization Control Register Function 0 Offset 6Ch Bit
6: InitDet looks exactly like what we want for that, and it is not
clobbered. Quoting from a really old BKDG (26094 Rev. 3.30 February 2006):
"INIT Detect (InitDet)—Bit 6. This bit may be used to distinguish
between an INIT and a warm/cold reset by setting the bit to 1 before an
initialization event is generated. This bit is cleared by a warm or cold
reset but not by an INIT."
Newer BKDGs say the same, so my question is how far back into the past
(in terms of CPUs supported by coreboot v2) and how far into the future
we can rely on this. It would certainly allow our stage0/stage1 code to
enjoy a cleaner design, not to mention improved readability.

Regards,
Carl-Daniel

--

-- 
http://www.hailfinger.org/

--
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

r854 - in coreboot-v3: northbridge/amd/k8 southbridge/amd/amd8111

Author: rminnich
Date: 2008-09-01 04:44:08 +0200 (Mon, 01 Sep 2008)
New Revision: 854

Modified:
   coreboot-v3/northbridge/amd/k8/coherent_ht.c
   coreboot-v3/northbridge/amd/k8/incoherent_ht.c
   coreboot-v3/northbridge/amd/k8/pci.c
   coreboot-v3/northbridge/amd/k8/raminit.c
   coreboot-v3/southbridge/amd/amd8111/acpi.c
Log:
This finishes the fix to log2. The computed dram size now matches the 
size indicated by byte 31 of SPD. 

Memory is still not working; hanging in dqs training. 

Signed-off-by: Ronald G. Minnich <rminnich <at> gmail.com>
Acked-by: Ronald G. Minnich <rminnich <at> gmail.com>

Modified: coreboot-v3/northbridge/amd/k8/coherent_ht.c
===================================================================
--- coreboot-v3/northbridge/amd/k8/coherent_ht.c	2008-08-31 20:39:48 UTC (rev 853)
+++ coreboot-v3/northbridge/amd/k8/coherent_ht.c	2008-09-01 02:44:08 UTC (rev 854)
@@ -322,7 +322,7 @@
 	freq_cap2 = read_freq_cap(node2, link2 + PCI_HT_CAP_HOST_FREQ_CAP);

 	/* Calculate the highest possible frequency */
-	freq = log2(freq_cap1 & freq_cap2);
+	freq = log2c(freq_cap1 & freq_cap2);

k8 and memory training

status:
train_DqsRcvrEn: end ctrl  0x0 0
 done
Ram4
stage1 returns
run_file returns with 0
Done RAM init code

Yep, we got through ram init code. Is it working? We'll see. It dies
in disable_car(), which I expected.

This is pretty neat .... I think disable_car() will be hard, but we'll
get it. I hope to have serengeti doing something interesting by the
end of the week. We'll see ... it's off vacation and back to work, so
it's back to nights and weekends, but we'll see.

thanks

ron

--
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: k8 and memory training

On Sun, Aug 31, 2008 at 4:45 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 <at> gmx.net> wrote:
> On 31.08.2008 08:46, ron minnich wrote:
>> see http://coreboot.pastebin.com/m354e6401
>>
>> I can't really tell if it's working.
>>
>
> I looked at the log and we're clearly doing something wrong odd. The
> execution order simply does not make that much sense.
>
> arch/x86/stage1.c:stage1_main()
> {
>  //stuff
>  global_vars_init();
>  hardware_stage1();

and here is where we would tie the actual uart hardware to port 3f8 such that:
>  uart_init();  // initialize serial port

works.

>  /* Exactly from now on we can use printk to the serial port.
>   * Celebrate this by printing a LB banner.
>   */
>  console_init();
>  //more stuff
> }
>
> mainboard/amd/serengeti/stage1.c:hardware_stage1()

/. effect:

from just now:
billybob2 writes "VIA has released a 113,800 line open source graphics
driver with full mode-setting support for CRT, LCD, and DVI devices
along with 2D, X-Video, and cursor acceleration. Harald Welte, VIA's
open source representative, states that the next step is to add 3D
(see preview), TV-out, and hardware codec support while integrating
this work with existing open source projects. VIA has pre-installed
Linux on a significant portion of the company's latest products,
including the EVEREX gPC2, 15.4" gBook, and CloudBook. It has also
helped port the open source CoreBoot BIOS (previously LinuxBIOS) to
several of its motherboards." VIA seems to be making good on the
promise of its open source initiative announced last April.

Neat stuff.

ron

--
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: /. effect:

Dear list,

Am Sonntag, den 31.08.2008, 23:56 -0700 schrieb ron minnich:
> from just now:
> billybob2 writes

[…]

> It has also
> helped port the open source CoreBoot BIOS (previously LinuxBIOS) to
> several of its motherboards."

Does anyone know about which boards they are talking? And have the
developers of coreboot experienced any improvement in cooperation?

Thanks,

Paul

--
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot