[Community] Welcome to new Project: Neo900

Dr. H. Nikolaus Schaller hns at goldelico.com
Sun Nov 3 08:39:58 CET 2013


Hi Neil,

Am 02.11.2013 um 23:07 schrieb NeilBrown:

> 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/

We now hit the 15k funding level! This means that we will be able to push the project to
build some working prototypes to learn about issues (as described below).

I should also note that the funding is not intended to be time limited. Because it is
more or less a voucher system. So if someone can't donate immediately, it is no
problem to jump in let's say next month. And, it is no problem if we go beyond 25k
because more donators (vouchers) mean that we can the expect to produce
more devices (which may also bring down the production cost to an even more
attractive level).

So we do exactly opposite as a standard fundraising, by having no limits (neither
in time nor in budget).

>>>> 
>>>> 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?

Well, I have not written this in detail. I think it is possible to use an IR interface
as a simple UART3, but there might be an issue with impulse shaping. AFAIR,
an IrDA transceiver works with impulses while UART uses states, i.e. sending
a 0x00-byte would be 9 clocks 0 on UART but 9 impulses on IrDA. This might
be incompatible. Anyways there is no problem of having both. Well, a space
problem.

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

I remember there might be a problem powering down the VAUX driving it only
but keeping the 1.8V. This might lead to some leakage current in the range of
seveal mA. But I have not looked how we did hook it up and what the driver is
really doing on suspend.

> 
> Don't know about RS232...  though I do know that plugging a serial cable in
> increase the current drain.

Yes, that is to be expected.

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

Yes, I remember - but have no new theory why it is so. The data sheet says
that holding reset of the USB3322 should power it completely down.

> 
>> 
>>> 
>>> 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
>> management.
>> 
>> 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?

No. We still need a new board and placing an DM3730 or an OMAP4 is
almost the same work. It is even higher with the OMAP4 since we don't know the 6k
pages TRM in all details. Thre may be things like a GPIO112 which is called such but
turns out to be a GPI112, i.e. input only. So you can use it as an interrupt input.
This is a mistake we did in the GTA04A2 revision (now fixed in A3 and later)...

> An OMAP4 (or better) would certainly make the project a lot more interesting
> to me personally.

Or besser = OMAP5 :) Well, they are not even available yet and TI has a different
sales model for OMAP4 and OMAP5. They sell to a selected group of module
manufacturers only, so we have no chance to get 200 or 2k chips. Not even 20k.
AFAIK, it starts with 500k chips/year that you can get them directly.

So this is unfortunately too much challenge so that we do not yet consider it.
It may become easier in ca. 12 months when the newest OMAP chips become
more widespread. But then they are no longer the cutting edge.

BR,
NIkolaus


More information about the Community mailing list