[Community] Welcome to new Project: Neo900

Sun Nov 3 10:17:07 CET 2013

Hello,

Do you have think about kickstater or other cloud founding site to finance your projects ?

Best regards

mparchet

> Le 3 nov. 2013 à 08:39, "Dr. H. Nikolaus Schaller" <hns at goldelico.com> a écrit :
> 
> 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
> _______________________________________________
> Community mailing list
> Community at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo/community
> http://www.openphoenux.org