Welcome

[Gerald A]

Hi Werner,

On Wed, Apr 15, 2009 at 11:03 AM, Werner Almesberger <werner at openmoko.org>wrote:

> Gerald A wrote:
> > Debugging here is boot debugging, not application debugging, just to
> > clarify, correct?
>
> It's system-level debugging: boot loader, kernel ailments, mystery
> freeze, etc. It can also be bug reports: if a user has a suspected
> kernel problem, it's often nice if one can ask them to connect a
> serial console and report what gets printed there, and when.


Ah, ok. So, I'm part right, then? :P

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.


> > My idea is old-school PC, the way they look for an MBR in a few different
> > areas (hard disk,
> > floppy) before launching into the code. We know by now that the boot
> flash
> > doesn't change
> > very often, usually hackers want to change the root and kernel images.
>
> Sure, that's basically what the NOR does. Only that it uses u-boot
> because that's what we had back then and writing a new boot loader
> (e.g., Qi) would have taken much longer than adapting u-boot.
>
> But again, the NOR has its cost. Even the chip itself is probably
> about as expensive as IDBG, and it only gives you the debricking,
> not all the other niceties.
>
> The 6410 has a built-in boot ROM that does what you're describing.
> So there you wouldn't need a debug board or an extra chip for
> debricking. They would still be useful for debugging, though.


My idea is to simplify, not complicate, so if the IDBG includes everything
the "unbrick protect" piece would, and more, you've sold me.


> > Ok, dumb question: Does this mean we don't need a graphics chip at all?
>
> 2442: no, but you have very very fast access from the CPU to the
> framebuffer. More than ten times faster than through the Glamo.
>
> For a sensibly programmed GUI, an "unaccelerated" 2442 should run
> circles around the Glamo. Idem for classical games.
>
> 6410: there are 2D and even 3D accelerator functions in the chip.


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

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?

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?

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".

Thanks,
Gerald.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/gta03/attachments/20090416/11b82229/attachment.htm