[coreboot] k8 and memory training

ron minnich rminnich at gmail.com
Mon Sep 1 08:51:01 CEST 2008

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


>  /* 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");
>  w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE);
>  post_code(POST_START_OF_MAIN);
> }
> Does it only look odd to me that we set up and initialize the serial
> port only after we already have printed lots of stuff which may never
> see the light of the day?

we see the light of day because it is (a) simnow or (b) the legacy
chain is set up right. NOt sure which yet.

> Three possible solutions:
> 1. Use the printk buffer to buffer messages until serial is fully set up.
> 2. Check a global variable which holds the status of serial and start
> using serial only after it has been set up completely. (We may need that
> anyway.)
> 3. Introduce hardware_early_stage1 which only sets up the console and
> anything needed by the console.

It does not really matter actually. You can't really talk to uart
until the setup_resource_map and enumerate_ht_chain have run, and
those functions are solidly debugged. I don't think it's worth too
much concern. This same situation was found on v2. I'm much more
worried about disable_car(), which is the current drop dead point.

I would put this on the "let's look at it later" list. It's not going
to hurt us now if ever.


More information about the coreboot mailing list