coreboot-3.0.811 Sun Aug 24 00:05:58 PDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member bootblock 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 bootblock LAR: File not found! LAR: Run file normal/initram/segment0 failed: No such file. Failed RAM init code
from simnow. Hey, it's a start.
ron
On 24.08.2008 18:12, ron minnich wrote:
coreboot-3.0.811 Sun Aug 24 00:05:58 PDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member bootblock 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 bootblock LAR: File not found! LAR: Run file normal/initram/segment0 failed: No such file. Failed RAM init code
from simnow. Hey, it's a start.
Doesn't compile for me. Did you forget to svn add northbridge/amd/k8/libstage1.c?
Regards, Carl-Daniel
OK, I will add this file. Also, temporarily, pcspeaker is out until I resolve the "out of room" problem on stage0. pcspeaker was not used at present anyway.
ron
On 24.08.2008 19:47, ron minnich wrote:
OK, I will add this file. Also, temporarily, pcspeaker is out until I resolve the "out of room" problem on stage0. pcspeaker was not used at present anyway.
Sorry, it still doesn't compile. New error message for the serengeti target: CC build/mainboard/amd/serengeti/option_table.o make: *** No rule to make target `/sources/tmptrees/corebootv3-tmp1/build/arch/x86/amd/model_fxx/stage1.o', needed by `/sources/tmptrees/corebootv3-tmp1/build/stage0.init'. Stop.
The arch/x86/amd/model_fxx directory doesn't exist in the tree. Either it needs to be added or the reference has to be changed to arch/x86/amd/k8.
Regards, Carl-Daniel
HI, I just made a mistake and deleted that file by accident.
!@$!@#$#@!!$@#$#@!
time for a break. DAMMIT!
ron
turns out I did not need the file.
Try again. Sorry, I can't do this full time today, but I"m watching the list.
ron
On 24.08.2008 20:11, ron minnich wrote:
turns out I did not need the file.
Try again. Sorry, I can't do this full time today, but I"m watching the list.
No problem. I'll keep testing. New error: make: *** No rule to make target `/sources/tmptrees/corebootv3-tmp1/northbridge/amd/k8/dqs.c', needed by `/sources/tmptrees/corebootv3-tmp1/build/coreboot.initram'. Stop.
Regards, Carl-Daniel
On Sun, Aug 24, 2008 at 11:14 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.08.2008 20:11, ron minnich wrote:
turns out I did not need the file.
Try again. Sorry, I can't do this full time today, but I"m watching the list.
No problem. I'll keep testing. New error: make: *** No rule to make target `/sources/tmptrees/corebootv3-tmp1/northbridge/amd/k8/dqs.c', needed by `/sources/tmptrees/corebootv3-tmp1/build/coreboot.initram'. Stop.
Regards, Carl-Daniel
ok that one is in too.
FYI, microcode will be in the lar as microcode/revision.mcf
where mcf is microcode file.
The initram code is responsible for finding and applying these as needed.
ron
On 24.08.2008 20:20, ron minnich wrote:
On Sun, Aug 24, 2008 at 11:14 AM, Carl-Daniel Hailfinger wrote:
On 24.08.2008 20:11, ron minnich wrote:
turns out I did not need the file.
Try again. Sorry, I can't do this full time today, but I"m watching the list.
No problem. I'll keep testing. New error: make: *** No rule to make target `/sources/tmptrees/corebootv3-tmp1/northbridge/amd/k8/dqs.c', needed by `/sources/tmptrees/corebootv3-tmp1/build/coreboot.initram'. Stop.
ok that one is in too.
Great, it compiles fine for me now.
FYI, microcode will be in the lar as microcode/revision.mcf
where mcf is microcode file.
The initram code is responsible for finding and applying these as needed.
See my other mail for that.
Regards, Carl-Daniel
go ahead and do a make -k so we get all the mistakes I made at one time :-)
ron
Note there are things left to do that are not at first obvious
1. all core0's in initram have to load microcode 2. as long as APs have to come up in initram, we might as well (last pass) fire up the core[1..n] and fix up their microcode too 3. PAE support is needed in initram
This support all exists, it's just a matter of arranging it.
ron
On 24.08.2008 19:49, ron minnich wrote:
Note there are things left to do that are not at first obvious
- all core0's in initram have to load microcode
This is going to hurt. You know that we only have 1k stack on all APs (that includes core0 of every non-BSP)? With some ugly trickery, I think 2k stack are possible, but you don't want to go there. Our v3 functions are not really optimized to fit into a small stack.
Loading microcode in initram also means we can't compress it because we can't decompress to RAM. And it enforces special placement of microcode in the LAR on boards like M57SLI rev 2.x.
- as long as APs have to come up in initram, we might as well (last
pass) fire up the core[1..n] and fix up their microcode too
Can't we postpone microcode loading to stage2 or at least past initram?
- PAE support is needed in initram
Lots of code is broken w.r.t. addresses above 4G. For example, the LAR code silently truncates all addresses to 32bit.
This support all exists, it's just a matter of arranging it.
I fear this might be a little more difficult than it looks at first glance, but I'm sure you can do it.
Regards, Carl-Daniel
On Sun, Aug 24, 2008 at 11:27 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.08.2008 19:49, ron minnich wrote:
Note there are things left to do that are not at first obvious
- all core0's in initram have to load microcode
This is going to hurt. You know that we only have 1k stack on all APs (that includes core0 of every non-BSP)? With some ugly trickery, I think 2k stack are possible, but you don't want to go there. Our v3 functions are not really optimized to fit into a small stack.
fam10 requires microcode load prior to ram setup. We have to make this work.
Can't we postpone microcode loading to stage2 or at least past initram?
AMD tells me not for fam10, so we might as well get it right from the start.
question: if BSP brings up ram, can't APs use that BSP ram? Is there any reason this would not work?
ron
Hi Marc,
we need your Fam10h expertise for this.
On 24.08.2008 20:32, ron minnich wrote:
On Sun, Aug 24, 2008 at 11:27 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.08.2008 19:49, ron minnich wrote:
Note there are things left to do that are not at first obvious
- all core0's in initram have to load microcode
This is going to hurt. You know that we only have 1k stack on all APs (that includes core0 of every non-BSP)? With some ugly trickery, I think 2k stack are possible, but you don't want to go there. Our v3 functions are not really optimized to fit into a small stack.
fam10 requires microcode load prior to ram setup. We have to make this work.
OK. It's unfortunate, but we can make it work.
Can't we postpone microcode loading to stage2 or at least past initram?
AMD tells me not for fam10, so we might as well get it right from the start.
question: if BSP brings up ram, can't APs use that BSP ram? Is there any reason this would not work?
I think Marc answered parts of this in the thread titled "[coreboot] K8 and Fam10 CAR". Other parts may be answered in the thread titled "[coreboot] AMD64 BKDG questions". These two threads are marked for re-reading in my mail folder because they have lots of valuable info. Looking at http://linuxbios.org/data/yhlu/LinuxBIOS_CAR_09142006.pdf your idea would probably need some re-architecting of the v3 code.
Anyway, Marc is probably the only person who can tell us for sure whether it would work.
Regards, Carl-Daniel
On Sun, Aug 24, 2008 at 12:07 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Can't we postpone microcode loading to stage2 or at least past initram?
AMD tells me not for fam10, so we might as well get it right from the start.
question: if BSP brings up ram, can't APs use that BSP ram? Is there any reason this would not work?
actually I think it already does ... I've been reading the bsp boot stuff a bit now.
your idea would probably need some re-architecting of the v3 code.
I'm not so sure of that, since I am hiding this part in initram.
Hang on and let's see how it goes in the next week.
ron
Carl-Daniel Hailfinger wrote:
Hi Marc,
we need your Fam10h expertise for this.
On 24.08.2008 20:32, ron minnich wrote:
On Sun, Aug 24, 2008 at 11:27 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.08.2008 19:49, ron minnich wrote:
Note there are things left to do that are not at first obvious
- all core0's in initram have to load microcode
This is going to hurt. You know that we only have 1k stack on all APs (that includes core0 of every non-BSP)? With some ugly trickery, I think 2k stack are possible, but you don't want to go there. Our v3 functions are not really optimized to fit into a small stack.
fam10 requires microcode load prior to ram setup. We have to make this work.
OK. It's unfortunate, but we can make it work.
1K of stack should still be plenty. If it is being used up we need to understand why. Each core should be able to snoop any cache so global vars and structs shouldn't be getting passed on the stack. They should be in the BSP cache/stack only.
Can't we postpone microcode loading to stage2 or at least past initram?
AMD tells me not for fam10, so we might as well get it right from the start.
question: if BSP brings up ram, can't APs use that BSP ram? Is there any reason this would not work?
I think Marc answered parts of this in the thread titled "[coreboot] K8 and Fam10 CAR". Other parts may be answered in the thread titled "[coreboot] AMD64 BKDG questions". These two threads are marked for re-reading in my mail folder because they have lots of valuable info. Looking at http://linuxbios.org/data/yhlu/LinuxBIOS_CAR_09142006.pdf your idea would probably need some re-architecting of the v3 code.
The BSP does all the memory init. It doesn't matter what CPU it is on. It makes one contiguous memory space and is shared by all cores. If the microcode is in the BSP cache (or in system memory later) the APs can load it, BUT I don't think that using the cache is too important. In my experience on fam10, it doesn't take long for the APs to load microcode off the ROM since they do it all at once.
Marc
Marc Jones wrote:
1K of stack should still be plenty. If it is being used up we need to understand why. Each core should be able to snoop any cache so global vars and structs shouldn't be getting passed on the stack. They should be in the BSP cache/stack only.
Other CPUs are not required in the scenario? Or is the cache available between those, too? (I would guess not)
I agree we should not go overboard with the amount of available stack. If we have 1K, that's perfectly fine. We're not doing KDE4 here.
Stefan Reinauer wrote:
Marc Jones wrote:
1K of stack should still be plenty. If it is being used up we need to understand why. Each core should be able to snoop any cache so global vars and structs shouldn't be getting passed on the stack. They should be in the BSP cache/stack only.
Other CPUs are not required in the scenario? Or is the cache available between those, too? (I would guess not)
APs should be able to read the BSP cache. I don't know that I have a working example of that. The sys_info struct should be an example.
Marc
On 24.08.2008 18:12, ron minnich wrote:
coreboot-3.0.811 Sun Aug 24 00:05:58 PDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member bootblock 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 bootblock LAR: File not found! LAR: Run file normal/initram/segment0 failed: No such file. Failed RAM init code
from simnow. Hey, it's a start.
Very strange. Does this also happen with the latest tree? It seems that your lar is completely empty except for the bootblock. Does a "make distclean" help?
Regards, Carl-Daniel
On Sun, Aug 24, 2008 at 11:39 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 24.08.2008 18:12, ron minnich wrote:
coreboot-3.0.811 Sun Aug 24 00:05:58 PDT 2008 starting... (console_loglevel=8) Choosing fallback boot. LAR: Attempting to open 'fallback/initram/segment0'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member bootblock 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 bootblock LAR: File not found! LAR: Run file normal/initram/segment0 failed: No such file. Failed RAM init code
from simnow. Hey, it's a start.
Very strange. Does this also happen with the latest tree? It seems that your lar is completely empty except for the bootblock. Does a "make distclean" help?
I think the ROM addressing is limited to 64k -- setup issue in stage0
ron
-
Carl-Daniel Hailfinger -
Marc Jones -
ron minnich -
Stefan Reinauer