After configuring the PLL registers on Geode LX, we have to reset the processor. However, nothing in the log tells the user why the processor is being reset. Example log follows:
LinuxBIOS-3.0.0 Fri Jan 11 15:53:52 MST 2008 starting... Choosing fallback boot. [...] Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. [...] LAR: CHECK normal/initram/segment0 @ 0xfffc49b0 start 0xfffc4a00 len 5564 reallen 5564 compression 0 entry 0x000010ca loadaddress 0x00000000 Entry point is 0xfffc5aca pll_reset: read msr 0x4c000014 _MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000398:0000181e Configuring PLL
LinuxBIOS-3.0.0 Fri Jan 11 15:53:52 MST 2008 starting... Choosing fallback boot. [...]
Print an informative message before resetting the processor.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv3-betterpllreset/arch/x86/geodelx/geodelx.c =================================================================== --- LinuxBIOSv3-betterpllreset/arch/x86/geodelx/geodelx.c (Revision 551) +++ LinuxBIOSv3-betterpllreset/arch/x86/geodelx/geodelx.c (Arbeitskopie) @@ -187,6 +187,8 @@ /* Use SWFLAGS to remember: "we've already been here". */ msr_glcp_sys_pll.lo |= (1 << RSTPLL_LOWER_SWFLAGS_SHIFT);
+ printk(BIOS_INFO, "Resetting the processor after PLL " + "configuration for the changes to take effect\n"); /* "Reset the chip" value */ msr_glcp_sys_pll.lo |= RSTPPL_LOWER_CHIP_RESET_SET; wrmsr(GLCP_SYS_RSTPLL, msr_glcp_sys_pll);
On Saturday 12 January 2008, ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
[BIOS_INFO vs. BIOS_EMERG]
Think about it this way: whichever log level is set, the information that a repeating log is intentional should be there.
Torsten
On 12.01.2008 01:53, ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
Thanks, r553.
Regards, Carl-Daniel
On Saturday 12 January 2008, Carl-Daniel Hailfinger wrote:
It shouldn't be BIOS_INFO. Resetting the machine is as fundamental as can be, so always tell this news if someone is listening (-> BIOS_EMERG). IMHO a few stars might be appropriate as well, but that's a matter of taste. Besides that Acked-by: Torsten Duwe duwe@lst.de
Torsten
On 12.01.2008 01:58, Torsten Duwe wrote:
Sorry, I saw your mail too late. I agree that it should have a high level, but since almost all messages in v3 are BIOS_DEBUG and even the first "LinuxBIOS v3.0.0 starting" is BIOS_INFO, I thought BIOS_INFO would be OK. BIOS_EMERG is a bit strong because every cold boot will trigger that code path by design.
Someone needs to go through all those printk() and decide which level is appropriate for each message.
Acked-by: Torsten Duwe duwe@lst.de
Thanks!
Regards, Carl-Daniel
On Saturday 12 January 2008, Carl-Daniel Hailfinger wrote:
BIOS_EMERG is a bit strong because every cold boot will trigger that code path by design.
OTOH after the new PLL values the machine _is_ unusable unless reset, right? As I replied to Ron, this message should be prioritised as high as the highest other message in that area, to always note that the reset is intentional.
Someone needs to go through all those printk() and decide which level is appropriate for each message.
If they're all BIOS_INFO then there's no problem :-)
Acked-by: Torsten Duwe duwe@lst.de
Thanks!
Welcome.
Torsten
-
Carl-Daniel Hailfinger -
ron minnich -
Torsten Duwe