[coreboot] k8 and memory training
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.
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.
> //more stuff
> printk(BIOS_ERR, "Stage1: enable rom ...\n");
> max = ARRAY_SIZE(register_values);
> setup_resource_map(register_values, max);
> printk(BIOS_ERR, "Done.\n");
> w83627hf_enable_serial(0x2e, SERIAL_DEV, SERIAL_IOBASE);
> 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
> 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