On Fri, Nov 14, 2008 at 11:00 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 15.11.2008 04:32, ron minnich wrote:<br>
> OK, another idea then. rework ROM layout.<br>
><br>
> top 32k: stage 1.<br>
> top-1 32k: fallback initram<br>
> top-2 32k: normal initram<br>
> The rest: the rest of lar.<br>
><br>
> waste memory? yes. But this would let us dump PIC.<br>
><br>
<br>
</div>I'd like to postpone the discussion about dropping PIC until it becomes<br>
really necessary. Why? Because there are lots of benefits in freely<br>
movable initram files inside LAR. For one, the ability to unpack<br>
fallback/initram and repackage it as normal/initram (or vice versa)<br>
would disappear. I couldn't justify that as a deliberate design decision<br>
in any discussion. Especially the fact that there is no way to recognize<br>
from a bare initram file whether it is fallback or normal is a killer<br>
for the desire to be able to unpack and repack a LAR. <br></blockquote><div><br>Should we just succumb to the way a factory BIOS does it? Initialize a minimal amount of ram with the default chipset timings in initram, then do a full blown ram init once we've got some real memory to work off of? Or would that not solve the problem?<br>
</div></div><br>-Corey<br>