You want to know what these things are?
On Thu, Apr 18, 2013 at 11:49 AM, Iurie iurcic@gmail.com 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 adurbin@chromium.org wrote:
On Wed, Apr 17, 2013 at 9:12 PM, Marc Jones marcj303@gmail.com 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