Add support for Cache-as-RAM on VIA C7 processors in v3. Finally.
Thanks to Jason Zhao we got a skeleton CAR code for VIA C7 based on older v2 code. I cleaned it up, modified the v3 stage0 code in lots of places as preparation for this and believe this is mostly merge-ready. Thanks to Bari Ari for getting the code to me for rewrite/review. Thanks to Corey Osgood who kept me going with helpful early tests and motivation. Thanks to everybody who reviewed my code.
CONFIG_CARTEST shall not be enabled (breaks the build).
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net Signed-off-by: Jason Zhao jasonzhao@viatech.com.cn
The v2 version was
Acked-by: Ronald G. Minnich rminnich@gmail.com Acked-by: Uwe Hermann uwe@hermann-uwe.de
Index: corebootv3-via_car/arch/x86/via/stage0.S =================================================================== --- corebootv3-via_car/arch/x86/via/stage0.S (Revision 0) +++ corebootv3-via_car/arch/x86/via/stage0.S (Revision 0) @@ -0,0 +1,207 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2000,2007 Ronald G. Minnich rminnich@gmail.com + * Copyright (C) 2005 Eswar Nallusamy, LANL + * Copyright (C) 2005 Tyan + * (Written by Yinghai Lu yhlu@tyan.com for Tyan) + * Copyright (C) 2007 coresystems GmbH + * (Written by Stefan Reinauer stepan@coresystems.de for coresystems GmbH) + * Copyright (C) 2007,2008 Carl-Daniel Hailfinger + * Copyright (C) 2008 VIA Technologies, Inc. + * (Written by Jason Zhao jasonzhao@viatech.com.cn for VIA) + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* Init code - Switch CPU to protected mode and enable Cache-as-Ram (CAR). */ + +#include <macros.h> + +#define ROM_CODE_SEG 0x08 +#define ROM_DATA_SEG 0x10 + +#define CACHE_RAM_CODE_SEG 0x18 +#define CACHE_RAM_DATA_SEG 0x20 + + .align 4 + .globl protected_stage0 +protected_stage0: + /* This code was used by v2. TODO. */ + lgdt %cs:gdtptr + ljmp $ROM_CODE_SEG, $__protected_stage0 + +.globl __protected_stage0 +__protected_stage0: + /* Save the BIST result. */ + movl %eax, %ebp + + port80_post(0x01) + + movw $ROM_DATA_SEG, %ax + movw %ax, %ds + movw %ax, %es + movw %ax, %ss + movw %ax, %fs + movw %ax, %gs + + /* Restore the BIST value to %eax. */ + movl %ebp, %eax + +.align 4 + +#define CacheSize CONFIG_CARSIZE +#define CacheBase CONFIG_CARBASE + +#define ASSEMBLY +#include <mtrr.h> + + /* Save the BIST result */ + movl %eax, %ebp + +CacheAsRam: + + /* disable cache */ + movl %cr0, %eax + orl $(0x1<<30),%eax + movl %eax,%cr0 + invd + + /* Set the default memory type and enable fixed and variable MTRRs */ + movl $MTRRdefType_MSR, %ecx + xorl %edx, %edx + /* Enable Variable and Fixed MTRRs */ + movl $0x00000c00, %eax + wrmsr + + /* Clear all MTRRs */ + xorl %edx, %edx + movl $fixed_mtrr_msr, %esi + +clear_fixed_var_mtrr: + lodsl (%esi), %eax + testl %eax, %eax + jz clear_fixed_var_mtrr_out + + movl %eax, %ecx + xorl %eax, %eax + wrmsr + + jmp clear_fixed_var_mtrr +clear_fixed_var_mtrr_out: + /* MTRRPhysBase */ + movl $0x200, %ecx + xorl %edx, %edx + movl $(CacheBase|MTRR_TYPE_WRBACK),%eax + wrmsr + + /* MTRRPhysMask */ + movl $0x201, %ecx + /* This assumes we never access addresses above 2^36 in CAR. */ + movl $0x0000000f,%edx + movl $(~(CacheSize-1)|0x800),%eax + wrmsr + +#if defined(CONFIG_XIP_ROM_SIZE) && defined(CONFIG_XIP_ROM_BASE) + /* enable write base caching so we can do execute in place + * on the flash rom. + */ + /* MTRRPhysBase */ + movl $0x202, %ecx + xorl %edx, %edx + movl $(XIP_ROM_BASE|MTRR_TYPE_WRBACK),%eax + wrmsr + + /* MTRRPhysMask */ + movl $0x203, %ecx + movl $0x0000000f,%edx + movl $(~(XIP_ROM_SIZE - 1) | 0x800), %eax + wrmsr +#endif /* XIP_ROM_SIZE && XIP_ROM_BASE */ + + movl $MTRRdefType_MSR, %ecx + xorl %edx, %edx + /* Enable Variable and Fixed MTRRs */ + movl $0x00000800, %eax + wrmsr + + /* enable cache */ + movl %cr0, %eax + andl $0x9fffffff,%eax + movl %eax, %cr0 + + /* Read the range with lodsl */ + movl $CacheBase, %esi + cld + movl $(CacheSize >> 2), %ecx + rep lodsl + + /* Clear the range */ + movl $CacheBase, %edi + movl $(CacheSize >> 2), %ecx + xorl %eax, %eax + rep stosl + +#if defined(CONFIG_XIP_ROM_SIZE) && defined(CONFIG_XIP_ROM_BASE) + /* Read the XIP area */ + movl XIP_ROM_BASE, %esi + movl $(XIP_ROM_SIZE>>2), %ecx + rep lodsl +#endif /* XIP_ROM_SIZE && XIP_ROM_BASE */ + + /* The key point of this CAR code is C7 cache does not turn into + * "no fill" mode, which is not compatible with general CAR code. + */ + + /* set up the stack pointer */ + movl $(CacheBase + CacheSize - 4), %eax + movl %eax, %esp + + /* Load a different set of data segments */ + movw $CACHE_RAM_DATA_SEG, %ax + movw %ax, %ds + movw %ax, %es + movw %ax, %ss + +lout: + /* Store zero for the pointer to the global variables. */ + pushl $0 + + /* Restore the BIST result. */ + movl %ebp, %eax + + /* We need to set ebp? No need. */ + movl %esp, %ebp + + /* Second parameter: init_detected */ + /* Store zero for the unused init_detected parameter. */ + pushl $0 + /* First parameter: bist */ + pushl %eax + call stage1_main + /* We will not go back. */ + +fixed_mtrr_msr: + .long 0x250, 0x258, 0x259 + .long 0x268, 0x269, 0x26A + .long 0x26B, 0x26C, 0x26D + .long 0x26E, 0x26F +var_mtrr_msr: + .long 0x200, 0x201, 0x202, 0x203 + .long 0x204, 0x205, 0x206, 0x207 + .long 0x208, 0x209, 0x20A, 0x20B + .long 0x20C, 0x20D, 0x20E, 0x20F + .long 0x000 /* NULL, end of table */ + +#include "../stage0_common.S" Index: corebootv3-via_car/arch/x86/Kconfig =================================================================== --- corebootv3-via_car/arch/x86/Kconfig (Revision 913) +++ corebootv3-via_car/arch/x86/Kconfig (Arbeitskopie) @@ -56,6 +56,15 @@ arch/x86/Makefile for more hints on possible values. It is usually set in mainboard/*/Kconfig.
+config CPU_VIA_C7 + boolean + help + CPU type. At the moment this option selects the reset vector and + Cache-as-RAM (CAR) implementation for a mainboard. See + arch/x86/Makefile for more hints on possible values. + It is usually set in mainboard/*/Kconfig. + + config CONFIG_HPET boolean depends CPU_AMD_K8 @@ -159,6 +168,7 @@ default 0x8f000 if CPU_I586 default 0x80000 if CPU_AMD_GEODELX default 0xc8000 if CPU_AMD_K8 + default 0xffef0000 if CPU_VIA_C7 help This option sets the base address of the area used for CAR.
@@ -167,6 +177,7 @@ default 0x1000 if CPU_I586 default 0x8000 if CPU_AMD_GEODELX default 0x8000 if CPU_AMD_K8 + default 0x8000 if CPU_VIA_C7 help This option sets the size of the area used for CAR.
@@ -175,6 +186,7 @@ default 0x1000 if CPU_I586 default 0x1000 if CPU_AMD_GEODELX default 0x2000 if CPU_AMD_K8 + default 0x1000 if CPU_VIA_C7 help This option sets the top of the memory area, in KiB, used for coreboot. Index: corebootv3-via_car/arch/x86/Makefile =================================================================== --- corebootv3-via_car/arch/x86/Makefile (Revision 913) +++ corebootv3-via_car/arch/x86/Makefile (Arbeitskopie) @@ -122,9 +122,13 @@ ifeq ($(CONFIG_CPU_AMD_K8),y) STAGE0_CAR_OBJ = amd/stage0.o STAGE0_ARCH_X86_SRC += amd/k8/stage1.c +else +ifeq ($(CONFIG_CPU_VIA_C7),y) + STAGE0_CAR_OBJ = via/stage0.o endif endif endif +endif
ifeq ($(CONFIG_PAYLOAD_NO_PREPARSE_ELF), y) PARSEELF =
Acked-by: Ronald G. Minnich rminnich@gmail.com
Note that it still won't build if CONFIG_XIP_ROM_{SIZE,BASE} are set but I still don't know why we even have CONFIG_XIP in v3 :-)
We can fix this but I'd like to start getting via bits into v3 asap.
ron
On 11.10.2008 01:03, ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
Thanks, committed in r915.
Note that it still won't build if CONFIG_XIP_ROM_{SIZE,BASE} are set but I still don't know why we even have CONFIG_XIP in v3 :-)
We can fix this but I'd like to start getting via bits into v3 asap.
Mostly I wanted to give Corey a chance to actually try some code which should work in theory.
The new code lists quite a few copyright holders and I believe most of them don't have any code in that file. I hope to revisit that problem in due time.
That XIP stuff needs a good explanation anyway. We may want to have it cover the boot block only or the bootblock and initram. Either way, reading the whole ROM to cache it may be less than useful and a severe performance killer early on.
Regards, Carl-Daniel
On Fri, Oct 10, 2008 at 8:14 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 11.10.2008 01:03, ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
Thanks, committed in r915.
Note that it still won't build if CONFIG_XIP_ROM_{SIZE,BASE} are set but I still don't know why we even have CONFIG_XIP in v3 :-)
We can fix this but I'd like to start getting via bits into v3 asap.
Mostly I wanted to give Corey a chance to actually try some code which should work in theory.
And work it does:
coreboot-3.0.916 Fri Oct 10 21:47:28 EDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: seen member normal/stage2/segment0@0xfff80600, size 1 LAR: seen member normal/stage2/segment1@0xfff80660, size 26338 LAR: seen member normal/stage2/segment2@0xfff86da0, size 6320
I'll be getting to ram init tomorrow ;)
Thanks! Corey
On Fri, Oct 10, 2008 at 9:50 PM, Corey Osgood corey.osgood@gmail.comwrote:
On Fri, Oct 10, 2008 at 8:14 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 11.10.2008 01:03, ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
Thanks, committed in r915.
Note that it still won't build if CONFIG_XIP_ROM_{SIZE,BASE} are set but I still don't know why we even have CONFIG_XIP in v3 :-)
We can fix this but I'd like to start getting via bits into v3 asap.
Mostly I wanted to give Corey a chance to actually try some code which should work in theory.
And work it does:
coreboot-3.0.916 Fri Oct 10 21:47:28 EDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: seen member normal/stage2/segment0@0xfff80600, size 1 LAR: seen member normal/stage2/segment1@0xfff80660, size 26338 LAR: seen member normal/stage2/segment2@0xfff86da0, size 6320
Stupid copy and paste error. I'm going to bed now...
coreboot-3.0.916 Fri Oct 10 21:47:28 EDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: seen member normal/stage2/segment0@0xfff80600, size 1 LAR: seen member normal/stage2/segment1@0xfff80660, size 26338 LAR: seen member normal/stage2/segment2@0xfff86da0, size 6320 LAR: seen member bootblock@0xffffafc0, size 20480 LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: CHECK normal/initram/segment0 @ 0xfff80400 start 0xfff80450 len 420 reallen 420 compression 0 entry 0x00000040 loadaddress 0x00000000 Entry point is 0xfff80490 RAM init code started. Nothing to do. printktest1: If the immediately preceding line does not say "Nothing to do.", then execution did not start at main() Trying absolute call from non-_MAINOBJECT XIP code. Absolute call successful. Done. run_file returns with 0 Done RAM init code
I'll be getting to ram init tomorrow ;)
Thanks! Corey
On 11.10.2008 03:51, Corey Osgood wrote:
On Fri, Oct 10, 2008 at 9:50 PM, Corey Osgood corey.osgood@gmail.comwrote:
On Fri, Oct 10, 2008 at 8:14 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 11.10.2008 01:03, ron minnich wrote:
Acked-by: Ronald G. Minnich rminnich@gmail.com
Thanks, committed in r915.
Note that it still won't build if CONFIG_XIP_ROM_{SIZE,BASE} are set but I still don't know why we even have CONFIG_XIP in v3 :-)
We can fix this but I'd like to start getting via bits into v3 asap.
Mostly I wanted to give Corey a chance to actually try some code which should work in theory.
And work it does:
Yay! It pays to reread code until no visible bugs or inconsistencies are left. I shall sell my 690G/SB600 board before I touch it and continue with "dry" coding. :-P
coreboot-3.0.916 Fri Oct 10 21:47:28 EDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: seen member normal/stage2/segment0@0xfff80600, size 1 LAR: seen member normal/stage2/segment1@0xfff80660, size 26338 LAR: seen member normal/stage2/segment2@0xfff86da0, size 6320
Stupid copy and paste error. I'm going to bed now...
coreboot-3.0.916 Fri Oct 10 21:47:28 EDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: seen member normal/stage2/segment0@0xfff80600, size 1 LAR: seen member normal/stage2/segment1@0xfff80660, size 26338 LAR: seen member normal/stage2/segment2@0xfff86da0, size 6320 LAR: seen member bootblock@0xffffafc0, size 20480 LAR: File not found! LAR: Run file fallback/initram/segment0 failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/option_table@0xfff80000, size 932 LAR: seen member normal/initram/segment0@0xfff80400, size 420 LAR: CHECK normal/initram/segment0 @ 0xfff80400 start 0xfff80450 len 420 reallen 420 compression 0 entry 0x00000040 loadaddress 0x00000000 Entry point is 0xfff80490 RAM init code started. Nothing to do. printktest1: If the immediately preceding line does not say "Nothing to do.", then execution did not start at main() Trying absolute call from non-_MAINOBJECT XIP code. Absolute call successful. Done. run_file returns with 0 Done RAM init code
I'll be getting to ram init tomorrow ;)
This will be a bit more difficult than you might at first expect. The following pieces of code are missing: - CAR disabling (doable, needs input from VIA) - Stack switching (really hard, but I have some concept in mind that will work).
However, RAM init itself won't be affected by this. The problems will start exactly at disable_car() and not before, so although you can rely on the code working until directly before disable_car(), after that your image will just crash, burn and/or insult your loved ones. You can insert a call to some memory test routine before disable_car() and it will give you reliable results about whether RAM init really worked.
Thanks!
You're welcome. Now it's your turn to shock Ron with some cool RAM init code. ;-)
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
That XIP stuff needs a good explanation anyway. We may want to have it cover the boot block only or the bootblock and initram. Either way, reading the whole ROM to cache it may be less than useful and a severe performance killer early on.
XIP could never perform better than fetching from cache except if the cache is broken. I would like XIP on/off to be an expert option in Kconfig unless we can reliably detect cache failure at runtime and decide on XIP or not from that.
On the other hand, too much logic this early on is not appealing.
//Peter
On 11.10.2008 07:18, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
That XIP stuff needs a good explanation anyway. We may want to have it cover the boot block only or the bootblock and initram. Either way, reading the whole ROM to cache it may be less than useful and a severe performance killer early on.
XIP could never perform better than fetching from cache except if the cache is broken. I would like XIP on/off to be an expert option in Kconfig unless we can reliably detect cache failure at runtime and decide on XIP or not from that.
We have to differentiate between two issues here: Marking the ROM as cached (good) and preemptively reading all of it to have it in cache (debatable).
On the other hand, too much logic this early on is not appealing.
I try to keep the complexity low. More patches will be forthcoming in due time.
Regards, Carl-Daniel
On Fri, Oct 10, 2008 at 10:18 PM, Peter Stuge peter@stuge.se wrote:
XIP could never perform better than fetching from cache except if the cache is broken.
If cache is broken, CAR is not going to work very well, we have no stack --> we're not going to boot anyway ...
I think we let the guys who make the chips deal with broken cache issues.
I am unable to see the need for XIP at this point but I am willing to be shown that I am wrong.
ron
On Sat, Oct 11, 2008 at 5:37 PM, ron minnich rminnich@gmail.com wrote:
On Fri, Oct 10, 2008 at 10:18 PM, Peter Stuge peter@stuge.se wrote:
XIP could never perform better than fetching from cache except if the cache is broken.
If cache is broken, CAR is not going to work very well, we have no stack --> we're not going to boot anyway ...
I think we let the guys who make the chips deal with broken cache issues.
I am unable to see the need for XIP at this point but I am willing to be shown that I am wrong.
Would using a small bit of XIP code enable us to detect broken cache and report that fact (post code, beep code, serial console printk) ?
Knowing that it's the CPU that is broken would allow one not to throw away the other good parts of the computer...
On Sat, Oct 11, 2008 at 1:24 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
Would using a small bit of XIP code enable us to detect broken cache and report that fact (post code, beep code, serial console printk) ?
if somebody wants to put it in early assembly I guess that's fine. But "broken" is very very tricky to really find.
trivially broken is not too hard however. ron
On 11.10.2008 22:32, ron minnich wrote:
On Sat, Oct 11, 2008 at 1:24 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
Would using a small bit of XIP code enable us to detect broken cache and report that fact (post code, beep code, serial console printk)
if somebody wants to put it in early assembly I guess that's fine. But "broken" is very very tricky to really find.
trivially broken is not too hard however.
We already have some code in the various stage0 implementations which can test for really obvious brokenness. The biggest problem with that code is that it needs some work and the multiple variants should be consolidated into one. This is on my (rather long) ToDo-List.
Regards, Carl-Daniel
On Sun, Oct 12, 2008 at 8:44 AM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 11.10.2008 22:32, ron minnich wrote:
On Sat, Oct 11, 2008 at 1:24 PM, Vincent Legoll vincent.legoll@gmail.com wrote:
Would using a small bit of XIP code enable us to detect broken cache and report that fact (post code, beep code, serial console printk)
if somebody wants to put it in early assembly I guess that's fine. But "broken" is very very tricky to really find.
trivially broken is not too hard however.
We already have some code in the various stage0 implementations which can test for really obvious brokenness. The biggest problem with that code is that it needs some work and the multiple variants should be consolidated into one. This is on my (rather long) ToDo-List.
Hmm, I'm having some problems with garbage on the serial console, and my serial init code seems to be in line with both the datasheet and v2, so I'm probably screwing something up. I'm using 0xffef0000 for the CAR base, 0x8000 for the CAR size, and 0x1000 for CBMEMK. Are those values somewhere near correct?
Thanks, Corey
On Sun, Oct 12, 2008 at 10:24 AM, Corey Osgood corey.osgood@gmail.com wrote:
Hmm, I'm having some problems with garbage on the serial console, and my serial init code seems to be in line with both the datasheet and v2, so I'm probably screwing something up. I'm using 0xffef0000 for the CAR base, 0x8000 for the CAR size, and 0x1000 for CBMEMK. Are those values somewhere near correct?
Sure, what's the garbage look like?
ron
On Sun, Oct 12, 2008 at 10:26 AM, ron minnich rminnich@gmail.com wrote:
On Sun, Oct 12, 2008 at 10:24 AM, Corey Osgood corey.osgood@gmail.com wrote:
Hmm, I'm having some problems with garbage on the serial console, and my serial init code seems to be in line with both the datasheet and v2, so I'm probably screwing something up. I'm using 0xffef0000 for the CAR base, 0x8000 for the CAR size, and 0x1000 for CBMEMK. Are those values somewhere near correct?
Sure, what's the garbage look like?
ron
BTW ... does CAR base have to be ffef0000, it can not be (e.g.) 88000? If this is the case I need to rewrite the startup sooner rather than later. Current CAR code assumes the CAR area is backed by memory.
ron
On 12.10.2008 19:27, ron minnich wrote:
On Sun, Oct 12, 2008 at 10:26 AM, ron minnich rminnich@gmail.com wrote:
On Sun, Oct 12, 2008 at 10:24 AM, Corey Osgood corey.osgood@gmail.com wrote:
Hmm, I'm having some problems with garbage on the serial console, and my serial init code seems to be in line with both the datasheet and v2, so I'm probably screwing something up. I'm using 0xffef0000 for the CAR base, 0x8000 for the CAR size, and 0x1000 for CBMEMK. Are those values somewhere near correct?
Sure, what's the garbage look like?
ron
BTW ... does CAR base have to be ffef0000, it can not be (e.g.) 88000?
Yes, unfortunately.
If this is the case I need to rewrite the startup sooner rather than later. Current CAR code assumes the CAR area is backed by memory.
Until the call to disable_car() we can deal with arbitrary CAR locations.
For the stack switch/rebuild I have some unfinished code you'd probably like. I'll post it in the next few days.
Regards, Carl-Daniel
On Sun, Oct 12, 2008 at 1:26 PM, ron minnich rminnich@gmail.com wrote:
On Sun, Oct 12, 2008 at 10:24 AM, Corey Osgood corey.osgood@gmail.com wrote:
Hmm, I'm having some problems with garbage on the serial console, and my serial init code seems to be in line with both the datasheet and v2, so
I'm
probably screwing something up. I'm using 0xffef0000 for the CAR base, 0x8000 for the CAR size, and 0x1000 for CBMEMK. Are those values
somewhere
near correct?
Sure, what's the garbage look like?
I'm attaching a minicom log file. From the looks of things, it also looks like I'm losing all output from stage0/1. The reason it boots twice is a GPIO that automatically resets the system if it isn't disabled, and it's not disabled yet.
Thanks, Corey
On Sun, Oct 12, 2008 at 11:04 AM, Corey Osgood corey.osgood@gmail.com wrote:
I'm attaching a minicom log file. From the looks of things, it also looks like I'm losing all output from stage0/1. The reason it boots twice is a GPIO that automatically resets the system if it isn't disabled, and it's not disabled yet.
the garbage may be your stage0/1 output. We've had trouble in the past with cheap uarts glitching badly when things like baud rate change. I actually don't think you need to worry about this garbage. I think you're doing very well indeed.
printk works, so your stack is working. So car is probably working. You ran initram. CAR is definitely working. You returned from initram. This is great.
Your biggest problem may be that you are not really getting initram right, which is why there is no stage2 output.
Oh, yeah, you are in trouble: LAR: Compression algorithm #1 (lzma) used Decoding error = 1
ram is no good. You need a test at the end of initram. But CAR is definitely solid I think. You need more debug in initram.
You're close.
I am going to be presenting CN700 at SC 08 I hope thanks to your fine work!
Ron
On Sun, Oct 12, 2008 at 2:15 PM, ron minnich rminnich@gmail.com wrote:
On Sun, Oct 12, 2008 at 11:04 AM, Corey Osgood corey.osgood@gmail.com wrote:
I'm attaching a minicom log file. From the looks of things, it also
looks
like I'm losing all output from stage0/1. The reason it boots twice is a GPIO that automatically resets the system if it isn't disabled, and it's
not
disabled yet.
the garbage may be your stage0/1 output. We've had trouble in the past with cheap uarts glitching badly when things like baud rate change. I actually don't think you need to worry about this garbage. I think you're doing very well indeed.
printk works, so your stack is working. So car is probably working. You ran initram. CAR is definitely working. You returned from initram. This is great.
Your biggest problem may be that you are not really getting initram right, which is why there is no stage2 output.
Oh, yeah, you are in trouble: LAR: Compression algorithm #1 (lzma) used Decoding error = 1
ram is no good. You need a test at the end of initram. But CAR is definitely solid I think. You need more debug in initram.
You're close.
I am going to be presenting CN700 at SC 08 I hope thanks to your fine work!
Ram init is currently a noop, I'm working on getting CS5536's SMBus functions (which are very clean) working in a more generic manner, and on vt8237. I'll get rid of any stage1 console output so the garbage will go away ;)
Thanks, Corey
On 12.10.2008 20:15, ron minnich wrote:
On Sun, Oct 12, 2008 at 11:04 AM, Corey Osgood corey.osgood@gmail.com wrote:
I'm attaching a minicom log file. From the looks of things, it also looks like I'm losing all output from stage0/1. The reason it boots twice is a GPIO that automatically resets the system if it isn't disabled, and it's not disabled yet.
the garbage may be your stage0/1 output. We've had trouble in the past with cheap uarts glitching badly when things like baud rate change. I actually don't think you need to worry about this garbage. I think you're doing very well indeed.
printk works, so your stack is working. So car is probably working. You ran initram. CAR is definitely working. You returned from initram. This is great.
Your biggest problem may be that you are not really getting initram right, which is why there is no stage2 output.
Oh, yeah, you are in trouble: LAR: Compression algorithm #1 (lzma) used Decoding error = 1
ram is no good. You need a test at the end of initram. But CAR is definitely solid I think. You need more debug in initram.
Sure. Even if his RAM init worked, the stack wouldn't be backed by RAM anymore after disable_car() due to the odd CAR location (and that's a hardware limitation).
You're close.
I am going to be presenting CN700 at SC 08 I hope thanks to your fine work!
I'm definitely looking forward to this.
Regards, Carl-Daniel
On 12.10.2008 20:04, Corey Osgood wrote:
I'm attaching a minicom log file. From the looks of things, it also looks like I'm losing all output from stage0/1.
AFAICS you're not losing any output from after serial init. Things look as I expect them to look. stage0 has no output and stage1 is rather silent (except the banner, which is indeed printed). The stuff before the banner comes from a not-yet-setup serial port. I said in the past that we shouldn't send stuff to serial before serial is set up, but my pleas have been ignored largely due to the fact that some hardware has working serial by default, so the problems were not seen in practice.
And yes, this is easy to fix. Keep a global variable (working_serial) and check it before sending stuff to the serial port. Set that variable directly after serial console init.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I said in the past that we shouldn't send stuff to serial before serial is set up, but my pleas have been ignored
Yes.
largely due to the fact that some hardware has working serial by default, so the problems were not seen in practice.
Not me. I ignore your plea because I think it is important for coreboot to communicate with the world very early on, and we should encourage it by making sure the port is enabled immediately.
//Peter
On Sun, Oct 12, 2008 at 11:04 PM, Peter Stuge peter@stuge.se wrote:
Carl-Daniel Hailfinger wrote:
I said in the past that we shouldn't send stuff to serial before serial is set up, but my pleas have been ignored
Yes.
largely due to the fact that some hardware has working serial by default, so the problems were not seen in practice.
Not me. I ignore your plea because I think it is important for coreboot to communicate with the world very early on, and we should encourage it by making sure the port is enabled immediately.
Is there a way we can have it both ways? You, with your well-behaving hardware, can have serial immediately, and I with my misbehaving hardware, can store stage1 output in the console log buffer until it can be printed in initram? Look at it this way: right now, I have limited options:
* Any init that can possibly fail with a message goes in initram. * Check from initram if stage1 init failed. * Assume stage1 init will never have any problems.
All options suck :(
-Corey
On 13.10.2008 05:30, Corey Osgood wrote:
On Sun, Oct 12, 2008 at 11:04 PM, Peter Stuge peter@stuge.se wrote:
Carl-Daniel Hailfinger wrote:
I said in the past that we shouldn't send stuff to serial before serial is set up, but my pleas have been ignored
Yes.
largely due to the fact that some hardware has working serial by default, so the problems were not seen in practice.
Not me. I ignore your plea because I think it is important for coreboot to communicate with the world very early on, and we should encourage it by making sure the port is enabled immediately.
Is there a way we can have it both ways? You, with your well-behaving hardware, can have serial immediately, and I with my misbehaving hardware, can store stage1 output in the console log buffer until it can be printed in initram?
Sure, we can make the behaviour a config option.
Look at it this way: right now, I have limited options:
- Any init that can possibly fail with a message goes in initram.
- Check from initram if stage1 init failed.
- Assume stage1 init will never have any problems.
All options suck :(
Heh. You basically want printk to buffer until ready, then flush to serial and have the buffering behaviour (yes/no) controlled by a config option. Or you could change the following sequence in arch/x86/stage1.c:stage1_main()
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(); if (bist!=0) { printk(BIOS_INFO, "BIST FAILED: %08x", bist); die(""); }
to
hardware_stage1_early(); // 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(); if (bist!=0) { printk(BIOS_INFO, "BIST FAILED: %08x", bist); die(""); }hardware_stage1();
To be honest, the current code does not make that much sense. We perform lots of initialization before we even check for catastrophic processor failure (bist!=0). For example, the serengeti target enables full ROM decode in hardware_stage1() instead of relying to the call to enable_rom() much later. It would be advisable at least to get printk running first and delay everything else until after printk over serial is active. Maybe we should even check bist as first instruction of stage1_main() or in stage0.
Regards, Carl-Daniel
ron minnich wrote:
.. but I'd like to start getting via bits into v3 asap.
I would really like us to do a design review round before substantial amounts of code supporting non-K8 systems are added to v3.
I realize everyone is eager to add as much as possible as quickly as possible to v3, but I believe that this kind of frenzy and not much forethought is the major reason for the mess that is v2.
I am not saying that we should stop working on v3 for two years. I'm asking that we stick to the Hamburg plan, i.e. to step back and evaluate (maybe tidy too) the code that is in v3 when simple (geodelx) and complex (k8) are both working.
I would be surprised if it took more than a week or two even if we are working distributed. A day or two if we were in the same room.
But I do believe it is important. There are several things to address. (ACPI/resume, dts, device model, interrupt routing to name just a few...)
This would affect all of stage2 - I don't think stage0 and stage1 can change much, and even if they do they are quite small codebases so not much work is needed to update even five or six of them. Those who are not so interested in following/doing the review could instead work on porting more CAR and RAM init code to v3.
Comments and flames, as always, most welcome.
//Peter
The only quibble I have is that the cn700 is actually simpler than the geode. The VSA makes geode a complex case. In some ways, due to the geodelink hardware and VSA, geode is more complex than k8. I believe that the cn700 is going to be our simplest case yet in v3.
I'm willing to commit a week to a design review. I have to wonder if we should not all be in the same room. February in brussels anyone? I seem to have missed the good times to be in europe with that idea! I should mention that Jan. in sonoma in california is actually pretty nice -- sunny and pretty good food and not all that cold. And all you .eu people would find it is cheap.
Otherwise, we could do video telecon via our computers for, say, two hours in morning and two hours in afternoon, with rounds of coding in between.
Stefan and I will be here in Ca last week of october, if you all want to fly out we can have the review at my house. Or do telecon/IRC action.
ron
On 11/10/08 07:13 +0200, Peter Stuge wrote:
ron minnich wrote: I am not saying that we should stop working on v3 for two years. I'm asking that we stick to the Hamburg plan, i.e. to step back and evaluate (maybe tidy too) the code that is in v3 when simple (geodelx) and complex (k8) are both working.
The problem is - they aren't working. Ron has done an exceptional job, but he is the only developer actually working at adding functional code to v3 on a regular basis. It is very frustrating that we have so many talented developers in the same community, and yet one guy is trying to build the rocket ship and everybody else just wants to wash and wax the exterior. I urge everybody to try v3 on real hardware (note that SimNow counts as real hardware for this excercise). If you think that what you see is of high enough enough quality to sell to your favorite OEM, then fine - we're done, and start cleaning up. But instead, I wager that you will find issues that you want fixed.
If everybody took a break from cleanup and fixed one problem a week, then in three months all that would be left are the cleanups.
I'll do my part - I will commit to a v3 patch a week (and a real change too, not just running indent).
Jordan
-
Carl-Daniel Hailfinger -
Corey Osgood -
Jordan Crouse -
Peter Stuge -
ron minnich -
Vincent Legoll