see http://coreboot.pastebin.com/m354e6401
I can't really tell if it's working.
I think there is a bug in simnow spd values. Computed size of the dimms from spd data is correct. The byte at 31 in SPD claims we only have 128 MB of RAM, which is wrong. It is right for one DIMM module, but we have two; it's a factor of two off.
So I've made it a warning, not an error, if spd byte 31 and computed size don't agree.
ron
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"); 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? 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.
My personal favourite is solution 3, with the additional option of solution 2 in case some serial chips are sensitive to usage before initialization.
Regards, Carl-Daniel
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 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.
ron
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
-
Carl-Daniel Hailfinger -
ron minnich