<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Oct 12, 2008 at 2:15 PM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</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 Sun, Oct 12, 2008 at 11:04 AM, Corey Osgood <<a href="mailto:corey.osgood@gmail.com">corey.osgood@gmail.com</a>> wrote:<br>
<br>
>  I'm attaching a minicom log file. From the looks of things, it also looks<br>
> like I'm losing all output from stage0/1. The reason it boots twice is a<br>
> GPIO that automatically resets the system if it isn't disabled, and it's not<br>
> disabled yet.<br>
><br>
<br>
</div>the garbage may be your stage0/1 output. We've had trouble in the past<br>
with cheap uarts glitching badly when things like baud rate change. I<br>
actually don't think you need to worry about this garbage. I think<br>
you're doing very well indeed.<br>
<br>
printk works, so your stack is working. So car is probably working.<br>
You ran initram. CAR is definitely working. You returned from initram.<br>
This is great.<br>
<br>
Your biggest problem may be that you are not really getting initram<br>
right, which is why there is no stage2 output.<br>
<br>
Oh, yeah, you are in trouble:<br>
LAR: Compression algorithm #1 (lzma) used<br>
Decoding error = 1<br>
<br>
ram is no good. You need a test at the end of initram. But CAR is<br>
definitely solid I think. You need more debug in initram.<br>
<br>
You're close.<br>
<br>
I am going to be presenting CN700 at SC 08 I hope thanks to your fine work!<font color="#888888"></font></blockquote><div><br>Ram init is currently a noop, I'm working on getting CS5536's SMBus functions (which are very clean) working in a more generic manner, and on vt8237. I'll get rid of any stage1 console output so the garbage will go away ;)<br>
<br>Thanks,<br>Corey<br></div></div><br></div>