<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 21, 2017 at 2:32 PM Paul Menzel via coreboot <<a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
Are there ways or strategies to preload the whole flash ROM chip<br class="gmail_msg">
content into memory for faster access right after RAM is set up for<br class="gmail_msg">
example? What does that depend on? Does that make any sense at all?<br class="gmail_msg">
<br class="gmail_msg"><br></blockquote><div><br></div><div>Back on older chipsets, and maybe on newer ones, there was a setting called shadow ram. You could set it so writes went to shadow ram, and later set it so reads did. Why? It was designed to let you copy slow flash into fast ram and then use ram.</div><div><br></div><div>So, </div><div>set shadow ram so that writes to the e0000-fffff range went to ram</div><div>memcpy(e0000, e0000, 128K)</div><div>set shadow ram so that reads to e0000-fffff go to ram</div><div><br></div><div>voila! you're fetching code/data from RAM. </div><div><br></div><div>Of course the RAM could then change after the copy.</div><div>This was why sometimes people would dd if=/dev/mem etc. etc. </div><div>and  they'd see that the output of dd differed from what they thought was in FLASH: because the bios would modify itself for various reasons. </div><div><br></div><div>So, your question makes a lot of sense. Or at least it used to :-)</div><div>Does it any more? That's an interesting question ... I see very few references to shadow ram in the code base any more.</div><div><br></div><div>Anyway ...</div><div><br></div><div>Now, linuxbios and (for a while) coreboot were designed to never persist. So the question becomes this: are you better off doing the full copy for a lot of ramstage code you'll use, at most, once; or are you better off letting the cache do its job once the CPU is working such that you don't need to mess with shadow ram? </div><div><br></div><div>factors include:</div><div>o to be sure your write shadow ram, you need to do a full read of flash and (uncached) write to ram. This will be pretty slow. How slow?</div><div>o is your cache much larger than 128k in size? i.e. what are the odds that you'll never flush a cache line from flash so you don't fetch a cache line from flash twice?</div><div>o how much of the flash do you need to copy? Do you really use ALL the code in flash or just parts? </div><div>o if you count on cache, then the flash data only moves from flash to cpu die as you execute coreboot. If you use shadow ram, the data path is more like flash -> cache -> ram ... and, hey, if your cache is big, then the result of all that copying to ram is a full cache. If you only use it once, storing to ram was kind of pointless. Of course, it could be writeback, not writethough, and so on.</div><div>o if you compress the ramstage, you're going to do that copy no matter what.</div><div><br></div><div>A quick git grep -i shadow.*ram shows very little usage nowadays. I have not looked at this in a very long time and my knowledge is almost certainly obsolete. Can someone more knowledgable comment on shadow ram usage in newer parts/mainboards?</div><div><br></div><div>Peter's answer is on the money.</div><div><br></div><div>ron</div><div> </div></div></div>