Re: [coreboot] GSOC-Implement advanced coreboot features on existing mainboards

[Aaron Durbin]

You want to know what these things are?

On Thu, Apr 18, 2013 at 11:49 AM, Iurie  wrote:
> hello,
> can you do me a favor and answer to this questions, please:
>
> i have not understood very well what is meant by
>
> global variables in romstage

romstage actually has 2 parts on x86 machines: 1 where memory isn't
available yet but the cache can be used as a backing store (named:
cache-as-ram). Global variables that are needed during this part of he
romstage can be annotated with a compiler attribute to resided in the
portion of the address space that is used for the cache-as-ram.

After memory is setup the cache-as-ram is torn down. This is where
things get a little peculiar. Those global variables still are linked
to reference the address space that *was* cache-as-ram which may just
be mmio space. Accessing them again won't give back the previously
written values. The code using this macro jumps through some weird
hoops to determine if cache-as-ram is still valid or not. It would be
really slick if these sorts of checks could be formalized and reused.

See this (http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/cpu/x8...)
for the CAR_GLOBAL macro. And the users of CAR_GLOBAL:

src/lib/timestamp.c

CAR_CBMEM is similar to CAR_GLOBAL. I'm not really quite sure why
there are 2 macros.

You can see how romstage is linked:
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/init/...
and you can see some of the interesting run-time checks to address the
correct variable:
http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/cbmem_cons...
> relocatable ramstage

This allows for relocating the ramstage portion of coreboot anywhere
within the 32-bit address space. Previously coreboot ramstage was
linked at 1MiB physical address. It could only reside there. However,
support was added to relocate the ramstage to any address. This is
done in romstage while loading the ramstage.

See this (http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/Kconfig;h=c3cc...)
for the description. It also requires using the relocatable modules
library and support for dynamic cbmem
(http://review.coreboot.org/gitweb?p=coreboot.git;a=commitdiff;h=df3a109b7290...).
The haswell cpu code (src/cpu/intel/haswell/romstage.c) has support
for both of these items.
> cbmem console

The cbmem console is a ram buffer that saves the console messages into
ram that can be retrieved later. The romstage support for it falls
into the CAR_GLOBAL thing we talked about before because it needs to
copy from cache-as-ram to main memory before cache-as-ram is torn
down.
> timestamps/performance data

This is something similar to cbmem console w.r.t. romstage utilizing
it. It's just a buffer of memory containing structures that define the
timestamp for a given check point.

http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/timest...

With that information one can get fairly granular timing metrics.
> namely the: romstage,romstage, cbmem console.
>
> and what is timestamps/performance data ?
>
> i thank you in advance for the answer

I hope that helps.

-Aaron
> best regards
>
> On 18 April 2013 14:49, Aaron Durbin  wrote:
> > On Wed, Apr 17, 2013 at 9:12 PM, Marc Jones  wrote:
> > > The AMD based boards would be good candidates for this type of work. You
> > > will need to research the details, but the chromebook mainboards have
> > > added
> > > several of these types of features that could be ported to other
> > > "active"
> > > mainboards.
> > >
> > > I revoemnd that you take a look at the git log for the google commits to
> > > get
> > > a handle on the details.
> >
> > I can also help w/ direction on some of these items.
> >
> > -Aaron