[coreboot] patch: init gx cache earlier.

Marc Jones marc.jones at amd.com
Tue Feb 5 18:42:13 CET 2008



ron minnich wrote:
> On Feb 5, 2008 4:00 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> 
>> Remember that we load stage 2 like a payload, so we'd have execution
>> order stage 0,1,3,4,5,2,3,4,5,realpayload.
> 
> Not if the stage definition is in main. I realized some time ago that
> arch/x86/stage1.c is misnamed (my fault) -- since it alls all the
> stages.
> 
> It's really what we used to call hardwaremain, I wonder if we should
> just call it coreboot main or something.
> 

I guess you can change the stage names and add a stageX for 
pre_payloaD() but that seems excessive.


> Marc, is it really possible to shadow bios if it is up in high memory?
> Or do we have to shadow fxxxx addresses?
> 

It wouldn't have to be there. It could be anywhere in main memory. 
After memory init in v2 the main coreboot image is copied to low memory 
and everything is run from there.

> If we have to shadow fxxxx addresses, then we need to do something like this:
> 
> assembly
> First C code calls stage1
> disable_car
> shadow boot block to fxxxx
> jump to entry point in fxxxx
> stage 2 payload, run it
> other code
> payload
> jump to payload
> 

Instead of a shadow step I would change stage2 to contain the lar other 
utilities and payload loader for a couple of reasons. It does make stage 
2 bigger but you still copy less to memory in the long run. In addition 
stage2 is compressed so I expect the growth in the ROM image wouldn't be 
too bad. Another advantage is that the bootblock(stage1.c) would not 
change as often since it won't do as much (I had to grow it to add the 
pre_payload call). Also, shadowing steps can be confusing to follow and 
that would be right in the middle of stage1.c and would grow the 
bootblock even more.

I am not saying we have to shadow. I think the patch I sent is a good 
enough solution for Geode. I don't want Geode to change the architecture 
and make things more difficult for CPUs that don't have these limitations.



Marc


-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors






More information about the coreboot mailing list