System reset seems to occur between 2 and 3, both of those logs attached, along with arch/x86/via/stage1.o With HALT_AFTER=3, the post code keeps changing, as expected with the system rebooting, with HALT_AFTER=2 it was 0xc2.<br>
<br>Thanks,<br>Corey<br><br><div class="gmail_quote">On Sat, Nov 1, 2008 at 7:38 AM, 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>
<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 01.11.2008 12:33, Carl-Daniel Hailfinger wrote:<br>
> Thanks. I now understand where parts of the garbage come from. Can you<br>
> try the attached patch? It should require no further fixups for COM2.<br>
><br>
> It would be great if you could use various values between 0 and 13<br>
> (inclusive) for the #define HALT_AFTER. The idea there is to<br>
> decrease/increase the value up to the biggest value where it doesn't<br>
> reboot automatically. The POST codes emitted by the diagnostic code<br>
> should be between 0xC0 and 0xCD. The last expected POST code for a given<br>
> HALT_AFTER is 0xC0+HALT_AFTER.<br>
><br>
> I'm also increasingly convinced that RAM is not working right,<br>
> especially for the area we use as stack. Can you enable ram_check() in<br>
> mainboard/.../initram.c again?<br>
><br>
<br>
</div>My apologies. I had attached an older version of the patch. Please try<br>
this one.<br>
Oh, and I'd be very interested in your build/arch/x86/via/stage1.o file.<br>
<div><div></div><div class="Wj3C7c"><br>
Regards,<br>
Carl-Daniel<br>
<br>
--<br>
<a href="http://www.hailfinger.org/" target="_blank">http://www.hailfinger.org/</a><br>
<br>
</div></div></blockquote></div><br>