Hi Werner,<br><br><div class="gmail_quote">On Wed, Apr 15, 2009 at 11:03 AM, Werner Almesberger <span dir="ltr"><<a href="mailto:werner@openmoko.org">werner@openmoko.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Gerald A wrote:<br>
> Debugging here is boot debugging, not application debugging, just to<br>
> clarify, correct?<br>
<br>
</div>It's system-level debugging: boot loader, kernel ailments, mystery<br>
freeze, etc. It can also be bug reports: if a user has a suspected<br>
kernel problem, it's often nice if one can ask them to connect a<br>
serial console and report what gets printed there, and when.</blockquote><div><br></div><div>Ah, ok. So, I'm part right, then? :P</div><div><br></div><div>The debug here isn't application debugging, but rather low level debug which will be useful for boot debug, kernel and driver debug, and interactions that tweak the kernel into a crash/oblivion.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> My idea is old-school PC, the way they look for an MBR in a few different<br>
> areas (hard disk,<br>
> floppy) before launching into the code. We know by now that the boot flash<br>
> doesn't change<br>
> very often, usually hackers want to change the root and kernel images.<br>
<br>
</div>Sure, that's basically what the NOR does. Only that it uses u-boot<br>
because that's what we had back then and writing a new boot loader<br>
(e.g., Qi) would have taken much longer than adapting u-boot.<br>
<br>
But again, the NOR has its cost. Even the chip itself is probably<br>
about as expensive as IDBG, and it only gives you the debricking,<br>
not all the other niceties.<br>
<br>
The 6410 has a built-in boot ROM that does what you're describing.<br>
So there you wouldn't need a debug board or an extra chip for<br>
debricking. They would still be useful for debugging, though.</blockquote><div><br></div><div>My idea is to simplify, not complicate, so if the IDBG includes everything the "unbrick protect" piece would, and more, you've sold me. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Ok, dumb question: Does this mean we don't need a graphics chip at all?<br>
<br>
</div>2442: no, but you have very very fast access from the CPU to the<br>
framebuffer. More than ten times faster than through the Glamo.<br>
<br>
For a sensibly programmed GUI, an "unaccelerated" 2442 should run<br>
circles around the Glamo. Idem for classical games.<br>
<br>
6410: there are 2D and even 3D accelerator functions in the chip.</blockquote><div><br></div><div>Ok, I was kind of wondering for a moment if there was some magical way of getting the contents of memory to the LCD. :P</div>
<div><br></div><div>Now, the bigger question: Where to go from here? We've chatted about fantasies and realities of how the overall process flows, but how can community members be a party to this process? </div><div><br>
</div><div>It seems hardware hacking can go on lots during the "brainstorming" phase of things. There were a couple of feedback loops in the process, any way to get hardware hackers involved at that level? I know at the prototype stage you are looking at limited yields and so forth, but from what I've gleaned out of the conversation it might be possible if one of those protos turns out to be business infeasible we could see if community hardware guys could re-work it into something better?</div>
<div><br></div><div>My line of thought here is having more options to choose from is better, although everyone has to understand that "working" doesn't mean "viable to be mass produced".</div><div>
<br></div><div>Thanks,</div><div>Gerald. </div></div>