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@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:
- Use the printk buffer to buffer messages until serial is fully set up.
- 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