[Community] Welcome to new Project: Neo900
neilb at suse.de
Sat Nov 2 23:07:32 CET 2013
On Sat, 2 Nov 2013 12:03:31 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:
> Hi Neil,
> Am 02.11.2013 um 09:46 schrieb NeilBrown:
> > On Thu, 31 Oct 2013 08:23:29 +0100 "Dr. H. Nikolaus Schaller"
> > <hns at goldelico.com> wrote:
> >> Hi,
> >> the new Neo900 (GTA04b7) project has been started within the OpenPhoenux community!
> >> It is now open for collecting donations to finance the initial development.
> >> For all details, please refer to the project home page: http://www.neo900.org/
> >> Let the Phoenux fly :)
> >> Nikolaus
> > Hi,
> > I've been reading through the web site and have a couple of comments.
> > 1/ From the 3x3 table on the front page:
> > IrDA and Consumer IR
> > Use your phone as a universal TV remote or...
> > connect the serial console via IrDA link. Low
> > level debugging couldn't be made easier.
> > unless you know something I don't, it isn't possible to do low-level debugging
> > over a serial console on the IrDA link. Certainly not possible to capture
> > early-boot messages.
> > For low-level kernel debugging I find a serial cable indispensable.
No reply to this bit? Should the reference to low level debugging through IR
be removed, or can someone tell me how to do it?
> > Also the "Feature Overview" in neo900-feasibility.pdf has an 'x' next to
> > 'IrDA' for both Neo900 possibilities. I guess 'x' must mean "yes". I
> > usually find "x" to me "no" and a "tick" to mean yes. Maybe it's a cultural
> > thing :-)
> Yes, appears to be so. Here we see an "x" like a checkmark "✓" meaning "yes".
> > Also the table doesn't list any Bluetooth for the GTA04. Not even an 'x'.
> Oops - that is an omission.
> I have fixed the document.
> > 2/ In neo900-feasibility.pdf
> > section 14 - Dual/Quad-core
> > - OMAP4: yes, Jorjin OMAP4 module, same CPU as PandaBoard; but we donʻt know
> > all hardware details and/or software (power management)
> > This seems to imply that we do know all the detail of power management for
> > the omap3. But we do not.
> > The power usage on the GTA04 is still woeful. This may not be directly
> > related to the OMAP3 software, but I suspect it is partly related.
> What I don't know is if all peripherals are powered down as much as possible.
> Suspects are the ITG3200 and the RS232/IrDA drivers.
I'm fairly sure the ITG3200 is being powered down. It isn't if you don't
have a driver and when I wrote a driver I save a couple of mA.
Don't know about RS232... though I do know that plugging a serial cable in
increase the current drain.
As I think I've said before, I'm very suspicious of internal USB.
It is the reason we cannot safely enter "off-mode", and small changes there
seem to have big effects on current. e.g. if I hold 'reset' low, current
usage goes up quite a bit.
> > In general the issue of power-management is largely missing from the
> > feasibility study. It should really state how power (in)efficient the GTA04
> > is and advise that there is no guarantee that the Neo900 will be any better.
> > (Anyone know how power-efficient the N900 is?).
> Yes, the N900 (RX51) is better than the GTA04. AFAIK, there is no study
> discussing why they are such better.
> > Also: what are the details that we don't know? I managed to find a TRM for
> > the OMAP4430 without much effort.
> Generally the evaluation result is that we know a lot more about OMAP3/GTA04.
> But nothing (except theory like a TRM) for the OMAP4. I.e. we could make a
> lot of mistakes hooking up the OMPA4 in a way that prevents optimal power
> And, if we take the Pandabaord as an example, it has no power management
> and therefore we don't have a power-efficiency optimzed blueprint to learn from.
> This sums up in that we know the OMAP3 better to optimize power demand than
> an OMAP4.
> With the current 2-PCB approach it could become feasible to develop an
> OMAP4 CPU board later.
That's an interesting idea ... would a replacement CPU board be significantly
less effort/cost than a whole new GTA04 board?
An OMAP4 (or better) would certainly make the project a lot more interesting
to me personally.
> Thanks for the helpful comments,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 828 bytes
Desc: not available
More information about the Community