[coreboot] k8 and memory training

[Carl-Daniel Hailfinger]

On 01.09.2008 08:51, ron minnich wrote:
> 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()
>> {
>>  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
>   

Thanks for the explanation. I didn't know that.

> 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.
>   

Sure, it is completely broken and trashes our stack. Yesterday I wanted
to post a patch/notice about this, but it seems the mail is still in my
draft folder. The global variable handling in the K8 code uses lots of
tricks which were appropriate in v3, but which completely kill v3.

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

In theory, if the default serial port is used as GPIOs for something
vital, writing to it could be rather harmful. I'll try to cook up a patch.

Regards,
Carl-Daniel

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