You want to know what these things are?
On Thu, Apr 18, 2013 at 11:49 AM, Iurie <[email protected]> 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/x86/car.h;h=2d2af03a370bdf49ad4052b534758fb211eeb779;hb=refs/heads/master#l24) 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/romstage.ld;h=88c56573ae3ffe4f94852d98f0446df627266d44;hb=refs/heads/master 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_console.c;h=2e22decd68a93bfaab3b7d807955cac1ca1fc3a9;hb=refs/heads/master#l90 > 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=c3cc6bffc672e8491f8e95d55c1236501338158f;hb=refs/heads/master#l385) 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=df3a109b72907419d503c81257ea241becdbb915). 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/timestamp.h;h=9dd0d0f5214d5404d650d7c4f019a9a79be7c08d;hb=refs/heads/master 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 <[email protected]> wrote: >> >> On Wed, Apr 17, 2013 at 9:12 PM, Marc Jones <[email protected]> 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 > > -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
