Re: Intel Atom
Joachim Steiger wrote: > also things like high-clocked ram (ddr compared to simple sdram) or > internal usb connections are energy suckers (thats why sdram with > <200mhz and things like sdio/spi/i2c/cmoslevel-serial is preferred to > usb and ddr ram. Shouldn't DDR ram use less power than SDR because of the lower voltage? (given that power scales linearly with clock, but quadratically with voltage) Ok, I guess mobile SDR might be using lower voltage than 3.3v already. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qualcomm Snapdragon? (Re: Intel Atom )
I tried to sketch my idea of extensions for openmoko and the result is placed in the wiki http://wiki.openmoko.org/wiki/Wishlist:Expansion_Back I dont know how feasible it can be in terms of design and power requirements. But thats what I had in my mind and I think thats what open source is all about. Express ur ideas:-) mokooo! On Thu, Aug 14, 2008 at 8:56 PM, Pritam Ghanghas <[EMAIL PROTECTED]> wrote: > But is there a way out. They way all these graphics chip companies > behave we will never get a > graphics chip on moko. For the worst case scenario that something as > bad as that happens on the binary driver side. Openmoko employees will > still be able to access the code as licensees. And I am not talking > about qualcomm. I am talking about omap 3530. TI is any time better > than qualcomm > Moreover as i had read in thread whose link i posted in the previous > post, that there are some reverse engineered drivers for older omaps > and there is hope of reuse and coming up with open only drivers. > and as stated above the performance without the proprietary stuff isnt > bad either > > our moko ! > > On Thu, Aug 14, 2008 at 7:09 PM, arne anka <[EMAIL PROTECTED]> wrote: >>> When the 2D/3D graphics drivers are released, only the kernel portions >>> will be GPL. The user-space libraries will be closed source by the >>> current plan of record. >>> >>> I guess this is good enough. I dont think we are getting anything more >>> with Glamo as well >> >> i don't think it is enough. >> not getting more with the glamo cannot be the standard and rational to put >> us in the same situation again. >> these only partial open drivers are almost as evil as the closed ones -- >> when something important changes you can't change the driver's internals >> and when qualcomm finally decides to drop the development of drivers you >> are stuck with driver rapidly becoming obsolete. >> i've lived w/ ati and nvidia drivers for the past few years and it ain't >> no fun. >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
You must start to realize just how low power mobile devices must be, to be actually useful. Geode, Atom, Fusion, everyone of these is a power hog compared to ARM. My vote goes for low clocked OMAP3530. Best regards Peter Kraker abatrour pravi: > Amd is working on their Fusion CPU/GPU. That would be perfect for mobile > devices ;) > Maybe gta04? > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
On Thu, 14 Aug 2008 23:30:01 -0700 Russell Sears <[EMAIL PROTECTED]>
babbled:
aaah - i was not really thinking of high quality audio filters - i was really
thinking "ok.. it's a phone - an embedded device. for entertainment and regular
daily use - we need really volume adjustment (to be able to soft-vary multiple
incoming audio streams) and mixing". yes. it's a limited view - but these are
limited devices :) for "practical usage" you need no fp math - not for the
basic audio stuff. sure. more complex filters (when doing actual audio
composition and mixing i would agree you will be wanting more here), but for
regular daily "realtime" use... i can't think of any need for fp math for
audio. (ok - i am skipping games here right now but even so most game audio
still falls into the category of soft-volume and mixing filters and playing
samples).
> Yes, but there's tons of legacy code that assumes an FPU. (ladspa plugins)
>
> Also, after some naive conversions from floating point to fixed point
> programming, I hit a situation where 32bit arithmetic doesn't quite cut it.
>
> Some filters want to multiply two floats together. You can do this to
> simulate floating point math:
>
> float f = ...; // 0 <= f < 1.
> int a, c;
>
> const int b = (int)(f * 65536.0)
>
> while(1) {
>... // update a
>c = a * b
>c >> 16
>... // do more math
> }
>
> Where a is signal data, perhaps dependent on past data, and b is a
> filter parameter. Some formulas derive b from user tunable parameters.
>
> In some corner cases, f is small (on the order of 1 / 2^16), which leads
> to rounding error assigning to the filter parameter b.
>
> This distorts the filter setup, and leads to artifacts, feedback loops,
> etc. Using 64 bit math better approximates the filter, and helps these
> corner cases a bit. There might also be cases where you'd want to carry
> 32 bits of precision throughout the calculation, though I haven't hit
> one yet.
>
> The good news is that the hit associated with 64 bit math (and a 48 bit
> filter parameter) is measurable, but tolerable on the FR.
>
> >
> >> On a related note (and perhaps on the wrong end of an NDA), any idea
> >> what the specs are on the glamo's built in openrisc processors?
> >
> > low to useless. it's slow. also not even under nda is there any info on just
> > how to program it. it's more of a control cpu - designed for keeping the
> > internal bits of glamo's silicon in line than actually doing any heavy
> > lifting of its own.
>
> Thanks for the info. That makes sense...
>
> -Rusty
--
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
Carsten Haitzler (The Rasterman) wrote:
> On Thu, 14 Aug 2008 21:54:34 -0700 Russell Sears <[EMAIL PROTECTED]>
> babbled:
>
>> Carsten Haitzler (The Rasterman) wrote:
>>
>>> though we need to accept that we need to move beyond SDR into DDR/DDR2 ram
>>> and higher clockrates anyway - we need more performance to do the things
>>> people want, we just need to do it with the right generation of SOC that
>>> has reigned these power requirements in a bit... and well - maybe accept we
>>> need a meatier battery :)
>>>
>> What about an FPU? It probably wouldn't eat much power, and would help
>> a *lot* for audio applications, since stuff wouldn't need to be
>> rewritten in fixed point arithmetic.
>
> modern arms have fpu's - FR doesn't but the ones i mentioned (omap3xxx and
> snapdragon) i am certain have fpu's.
>
> nb. u dont need fp - it's just "lazy programming" to have used floating point
> math for the audio - it can be trivially done in integer space. with 16bit
> input you can easily do all your work in 32bit scratch-pad registers (no need
> for 64bit math). as such this is NOT a reason for an fpu. for 3d geometry and
> so on it definitely makes sense though. and with the more modern systems come
> graphics units capable of something vaguely decent graphics-wise :) so an fpu
> makes sense there. :)
Yes, but there's tons of legacy code that assumes an FPU. (ladspa plugins)
Also, after some naive conversions from floating point to fixed point
programming, I hit a situation where 32bit arithmetic doesn't quite cut it.
Some filters want to multiply two floats together. You can do this to
simulate floating point math:
float f = ...; // 0 <= f < 1.
int a, c;
const int b = (int)(f * 65536.0)
while(1) {
... // update a
c = a * b
c >> 16
... // do more math
}
Where a is signal data, perhaps dependent on past data, and b is a
filter parameter. Some formulas derive b from user tunable parameters.
In some corner cases, f is small (on the order of 1 / 2^16), which leads
to rounding error assigning to the filter parameter b.
This distorts the filter setup, and leads to artifacts, feedback loops,
etc. Using 64 bit math better approximates the filter, and helps these
corner cases a bit. There might also be cases where you'd want to carry
32 bits of precision throughout the calculation, though I haven't hit
one yet.
The good news is that the hit associated with 64 bit math (and a 48 bit
filter parameter) is measurable, but tolerable on the FR.
>
>> On a related note (and perhaps on the wrong end of an NDA), any idea
>> what the specs are on the glamo's built in openrisc processors?
>
> low to useless. it's slow. also not even under nda is there any info on just
> how to program it. it's more of a control cpu - designed for keeping the
> internal bits of glamo's silicon in line than actually doing any heavy lifting
> of its own.
Thanks for the info. That makes sense...
-Rusty
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
On Thu, 14 Aug 2008 23:25:14 -0700 (PDT) abatrour <[EMAIL PROTECTED]> babbled: > > Amd is working on their Fusion CPU/GPU. That would be perfect for mobile > devices ;) > Maybe gta04? call us when they get to the 1 watt world. for now and for a while to come both intel and amd's offerings are far far far from mobile land. sure- given time they may eventually get there - but remember that ARM isn't standing still and there is a reason ARM is the king of the hill in embedded (pretty much). -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
Amd is working on their Fusion CPU/GPU. That would be perfect for mobile devices ;) Maybe gta04? -- View this message in context: http://n2.nabble.com/Intel-Atom-tp723106p725752.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
On Thu, 14 Aug 2008 21:54:34 -0700 Russell Sears <[EMAIL PROTECTED]> babbled: > Carsten Haitzler (The Rasterman) wrote: > > > though we need to accept that we need to move beyond SDR into DDR/DDR2 ram > > and higher clockrates anyway - we need more performance to do the things > > people want, we just need to do it with the right generation of SOC that > > has reigned these power requirements in a bit... and well - maybe accept we > > need a meatier battery :) > > > > What about an FPU? It probably wouldn't eat much power, and would help > a *lot* for audio applications, since stuff wouldn't need to be > rewritten in fixed point arithmetic. modern arms have fpu's - FR doesn't but the ones i mentioned (omap3xxx and snapdragon) i am certain have fpu's. nb. u dont need fp - it's just "lazy programming" to have used floating point math for the audio - it can be trivially done in integer space. with 16bit input you can easily do all your work in 32bit scratch-pad registers (no need for 64bit math). as such this is NOT a reason for an fpu. for 3d geometry and so on it definitely makes sense though. and with the more modern systems come graphics units capable of something vaguely decent graphics-wise :) so an fpu makes sense there. :) > On a related note (and perhaps on the wrong end of an NDA), any idea > what the specs are on the glamo's built in openrisc processors? low to useless. it's slow. also not even under nda is there any info on just how to program it. it's more of a control cpu - designed for keeping the internal bits of glamo's silicon in line than actually doing any heavy lifting of its own. > Can they do floating point? Randomly access memory? How many of them > are there? > > If they're beefy enough, with the right drivers (like CUDA), I think > we'd have the bus bandwidth to offload audio processing (ogg decoding) > to them, assuming the bus is symmetric: > > 48khz * 16bit/sample * 2channels = 187.5 kilobytes / sec = 1.4 mbit/sec > > -Rusty > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
Carsten Haitzler (The Rasterman) wrote: > though we need to accept that we need to move beyond SDR into DDR/DDR2 ram and > higher clockrates anyway - we need more performance to do the things people > want, we just need to do it with the right generation of SOC that has reigned > these power requirements in a bit... and well - maybe accept we need a meatier > battery :) > What about an FPU? It probably wouldn't eat much power, and would help a *lot* for audio applications, since stuff wouldn't need to be rewritten in fixed point arithmetic. On a related note (and perhaps on the wrong end of an NDA), any idea what the specs are on the glamo's built in openrisc processors? Can they do floating point? Randomly access memory? How many of them are there? If they're beefy enough, with the right drivers (like CUDA), I think we'd have the bus bandwidth to offload audio processing (ogg decoding) to them, assuming the bus is symmetric: 48khz * 16bit/sample * 2channels = 187.5 kilobytes / sec = 1.4 mbit/sec -Rusty ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
On Thu, 14 Aug 2008 20:32:22 +0200 Joachim Steiger <[EMAIL PROTECTED]> babbled: > qrazi wrote: > > The test referred to are with the nettop version of the Atom, the Atom N230. > > That CPU is paired with a standard 945GC chipset, which consumes between 15 > > and 20 Watt. Hence the high power draws in those reviews. > > > > Intel also has the Z series, which include speedstep for even lower > > powerconsumption for the CPU itself, but they are also to be used with the > > Intel US15 mobile chipset. For a 1.6 GHz Z530 Atom, with the US15 chipset, a > > maximum draw of 5 Watt is reported. That is way lower then the combination > > that PC Perspective has tested. > > > > Although probably still not low enough for use in a phone. That however > > might come in future generations, since Intels plans are to include more, if > > not all, of the chipset functions into the cpu itself. > > > > thanks for summarizing it so well > thats also my conclusion: x86 is not ready yet for really mobile use. > we should evaluate it more when they can punch the '<1W when in use' limit. > > for comparison: our cpu currently uses <90mA when in use. > add the chipset, the lcm and interfaces (don't forget wifi, bt and gsm) > and then see battery sizes and capacity -> for a reasonable standby AND > talk time we need to not peak far beyond 1W when in use and be far > beyond that all the rest of the time. > also things like high-clocked ram (ddr compared to simple sdram) or > internal usb connections are energy suckers (thats why sdram with > <200mhz and things like sdio/spi/i2c/cmoslevel-serial is preferred to > usb and ddr ram. > > its always getting things into a tricky balance to have something usable > at the end (and not a 'see how fluid it moves the icon' - 'oh.. batter > is empty' - showcase ;) aye - and even so. arm-based solutions are cranking up the power. omap 3xxx and qualcomm's snapdragon are not slow-pokes. and they are far beyond anything intel has in performance-per-watt when you are in the 1watt (give or take) world. indeed you are very right - when intel have scaled DOWN to the existing embedded world.. we can talk, but as such an x86 phone is only a "development convenience" compared to arm (no cross-compiling from an x86 desktop). though we need to accept that we need to move beyond SDR into DDR/DDR2 ram and higher clockrates anyway - we need more performance to do the things people want, we just need to do it with the right generation of SOC that has reigned these power requirements in a bit... and well - maybe accept we need a meatier battery :) -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
I totally think running an x86 CPU in the phone would be great for opening up possibilities for hobbyist developers. ARM may be more efficient but if this project is meant to really enable DIY projects, I think x86 would be fantastic. Part of what we've got to also keep in mind is that the power specs we see now are for today - where are they going to be in a year? What has the trend for improvement been? Perhaps if there's a strong relationship with Intel to be leveraged, we could ping them on the idea. If we can deliver them a list of power requirements it's possible they may be very interested in finding little tweaks and offering suggestions on how to make that work. I'm all for x86 on the phone. I think it'd only serve to open the platform up even more and isn't that more or less the point? On Thu, Aug 14, 2008 at 1:49 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: > Joachim > > > thats also my conclusion: x86 is not ready yet for really mobile use. > > fwiw, atom may not be ready, but there are a couple of system-on-chip > x86 cpus out there that might be interesting. Just how much power is > still in question, but there's geode from AMD, some VIA offerings, and > a couple from lesser-known manufacturers like Tri-M. > > -- > Brad > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
Joachim > thats also my conclusion: x86 is not ready yet for really mobile use. fwiw, atom may not be ready, but there are a couple of system-on-chip x86 cpus out there that might be interesting. Just how much power is still in question, but there's geode from AMD, some VIA offerings, and a couple from lesser-known manufacturers like Tri-M. -- Brad ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
qrazi wrote: > The test referred to are with the nettop version of the Atom, the Atom N230. > That CPU is paired with a standard 945GC chipset, which consumes between 15 > and 20 Watt. Hence the high power draws in those reviews. > > Intel also has the Z series, which include speedstep for even lower > powerconsumption for the CPU itself, but they are also to be used with the > Intel US15 mobile chipset. For a 1.6 GHz Z530 Atom, with the US15 chipset, a > maximum draw of 5 Watt is reported. That is way lower then the combination > that PC Perspective has tested. > > Although probably still not low enough for use in a phone. That however > might come in future generations, since Intels plans are to include more, if > not all, of the chipset functions into the cpu itself. > thanks for summarizing it so well thats also my conclusion: x86 is not ready yet for really mobile use. we should evaluate it more when they can punch the '<1W when in use' limit. for comparison: our cpu currently uses <90mA when in use. add the chipset, the lcm and interfaces (don't forget wifi, bt and gsm) and then see battery sizes and capacity -> for a reasonable standby AND talk time we need to not peak far beyond 1W when in use and be far beyond that all the rest of the time. also things like high-clocked ram (ddr compared to simple sdram) or internal usb connections are energy suckers (thats why sdram with <200mhz and things like sdio/spi/i2c/cmoslevel-serial is preferred to usb and ddr ram. its always getting things into a tricky balance to have something usable at the end (and not a 'see how fluid it moves the icon' - 'oh.. batter is empty' - showcase ;) kind regards -- Joachim Steiger Openmoko Central Services ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qualcomm Snapdragon? (Re: Intel Atom )
But is there a way out. They way all these graphics chip companies behave we will never get a graphics chip on moko. For the worst case scenario that something as bad as that happens on the binary driver side. Openmoko employees will still be able to access the code as licensees. And I am not talking about qualcomm. I am talking about omap 3530. TI is any time better than qualcomm Moreover as i had read in thread whose link i posted in the previous post, that there are some reverse engineered drivers for older omaps and there is hope of reuse and coming up with open only drivers. and as stated above the performance without the proprietary stuff isnt bad either our moko ! On Thu, Aug 14, 2008 at 7:09 PM, arne anka <[EMAIL PROTECTED]> wrote: >> When the 2D/3D graphics drivers are released, only the kernel portions >> will be GPL. The user-space libraries will be closed source by the >> current plan of record. >> >> I guess this is good enough. I dont think we are getting anything more >> with Glamo as well > > i don't think it is enough. > not getting more with the glamo cannot be the standard and rational to put > us in the same situation again. > these only partial open drivers are almost as evil as the closed ones -- > when something important changes you can't change the driver's internals > and when qualcomm finally decides to drop the development of drivers you > are stuck with driver rapidly becoming obsolete. > i've lived w/ ati and nvidia drivers for the past few years and it ain't > no fun. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qualcomm Snapdragon? (Re: Intel Atom )
> When the 2D/3D graphics drivers are released, only the kernel portions > will be GPL. The user-space libraries will be closed source by the > current plan of record. > > I guess this is good enough. I dont think we are getting anything more > with Glamo as well i don't think it is enough. not getting more with the glamo cannot be the standard and rational to put us in the same situation again. these only partial open drivers are almost as evil as the closed ones -- when something important changes you can't change the driver's internals and when qualcomm finally decides to drop the development of drivers you are stuck with driver rapidly becoming obsolete. i've lived w/ ati and nvidia drivers for the past few years and it ain't no fun. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qualcomm Snapdragon? (Re: Intel Atom )
All this discussion is going on this thread http://groups.google.com/group/beagleboard/browse_thread/thread/312ee38463d91380 On Thu, Aug 14, 2008 at 6:55 PM, Pritam Ghanghas <[EMAIL PROTECTED]> wrote: > got some info on TI 3530 and beagleborad: > > Que: video quality with only the openly available information and code? > Ans: The FFmpeg 720p demo was put together with all open source software. >Video using the DSP is pending. > > Que: how open will be the various interfaces and drivers > Ans: The DSP interface software hasn't been released to open source yet. > It is in the plan to provide them as open source, but they will be > provided as GPL in the kernel and TI proprietary licensing (partial > source) in the user space first. The DSP-side portions, namely the TI > codecs, will still be closed source. > > When the 2D/3D graphics drivers are released, only the kernel portions > will be GPL. The user-space libraries will be closed source by the > current plan of record. > > I guess this is good enough. I dont think we are getting anything more > with Glamo as well > > our moko!! > > > On Thu, Aug 14, 2008 at 1:52 PM, David Pottage <[EMAIL PROTECTED]> wrote: >> >> On Thu, August 14, 2008 4:25 am, Urivan Saaib wrote: >>> What about the QC Snapdragon? >> >> >> >> Qualcomm have a history of being a very litigious company. Just look at >> their ongoing litigation with Nokia over CDMA patents. I would be worried >> that if we got on the wrong side of them, they would sue OpenMoko faster >> than you can say "software patent". >> >> With someone like Qualcomm, I would want all the drivers and all the docs >> under a GPL license before I would consider them, preferably GPL-3 with >> it's even stronger protections against software patents and similar >> tactics. >> >> -- >> David Pottage >> >> Error compiling committee.c To many arguments to function. >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qualcomm Snapdragon? (Re: Intel Atom )
got some info on TI 3530 and beagleborad: Que: video quality with only the openly available information and code? Ans: The FFmpeg 720p demo was put together with all open source software. Video using the DSP is pending. Que: how open will be the various interfaces and drivers Ans: The DSP interface software hasn't been released to open source yet. It is in the plan to provide them as open source, but they will be provided as GPL in the kernel and TI proprietary licensing (partial source) in the user space first. The DSP-side portions, namely the TI codecs, will still be closed source. When the 2D/3D graphics drivers are released, only the kernel portions will be GPL. The user-space libraries will be closed source by the current plan of record. I guess this is good enough. I dont think we are getting anything more with Glamo as well our moko!! On Thu, Aug 14, 2008 at 1:52 PM, David Pottage <[EMAIL PROTECTED]> wrote: > > On Thu, August 14, 2008 4:25 am, Urivan Saaib wrote: >> What about the QC Snapdragon? > > > > Qualcomm have a history of being a very litigious company. Just look at > their ongoing litigation with Nokia over CDMA patents. I would be worried > that if we got on the wrong side of them, they would sue OpenMoko faster > than you can say "software patent". > > With someone like Qualcomm, I would want all the drivers and all the docs > under a GPL license before I would consider them, preferably GPL-3 with > it's even stronger protections against software patents and similar > tactics. > > -- > David Pottage > > Error compiling committee.c To many arguments to function. > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qualcomm Snapdragon? (Re: Intel Atom )
On Thu, August 14, 2008 4:25 am, Urivan Saaib wrote: > What about the QC Snapdragon? Qualcomm have a history of being a very litigious company. Just look at their ongoing litigation with Nokia over CDMA patents. I would be worried that if we got on the wrong side of them, they would sue OpenMoko faster than you can say "software patent". With someone like Qualcomm, I would want all the drivers and all the docs under a GPL license before I would consider them, preferably GPL-3 with it's even stronger protections against software patents and similar tactics. -- David Pottage Error compiling committee.c To many arguments to function. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
The test referred to are with the nettop version of the Atom, the Atom N230. That CPU is paired with a standard 945GC chipset, which consumes between 15 and 20 Watt. Hence the high power draws in those reviews. Intel also has the Z series, which include speedstep for even lower powerconsumption for the CPU itself, but they are also to be used with the Intel US15 mobile chipset. For a 1.6 GHz Z530 Atom, with the US15 chipset, a maximum draw of 5 Watt is reported. That is way lower then the combination that PC Perspective has tested. Although probably still not low enough for use in a phone. That however might come in future generations, since Intels plans are to include more, if not all, of the chipset functions into the cpu itself. Shawn Rutledge wrote: > > On Wed, Aug 13, 2008 at 8:55 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: >> I've heard the support chips for atom have not been optimized for >> saving power yet, so it may be another generation before atom + >> chipset + solid state drive will be within any kind of reasonable >> power budget for a handheld. > > Yeah no kidding... > > http://www.pcper.com/article.php?aid=597&type=expert&pid=8 > > See how the "entire system" power is 60 watts max, and doesn't vary > much with the load? and here: > > http://www.pcper.com/article.php?aid=597&type=expert&pid=2 > > funny how the chipset has a big heatsink with a fan, while the > processor has a small heatsink and no fan. :-) At least they are > competing favorably with VIA for the mini-ITX boards though. > >> If they haven't already, they also need to engineer an instant wakeup >> (acpi suspend/resume is abysmal) > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/Intel-Atom-tp723106p723658.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
Jeffery, can you add the Atom chip to our 'Chip Scouting' section at http://wiki.openmoko.org/wiki/MokoForesight ? Also in the future, any hardware related mails should go to [EMAIL PROTECTED] I am getting our Electrical Engineers to subscribe to that list, and we do take the Chip Scouting thing very serious. Just this morning we had 2 people from Telit visit us, after someone added the UC-864 module to the Chip Scouting section, and we were glad to hear that open documentation is part of Telit's business strategy. Talking about Intel, I think I can say publicly that we have a very good relationship with Intel, they gave us a Menlow development machine a while ago and we did some experiments with it. We would be delighted to work with Intel on upcoming phone models, especially if they continue with their 'open documentation' policy, which they seem to be serious about. One really cool thing about Intel is that they release some of their documentation under a Creative Commons license. Many vendors still don't do that. Even if their documentation is 'open', redistribution is forbidden. That means we cannot put these files onto our servers, we have to link to their servers. And if they take down the files some time later, people may be out of luck and we cannot offer help. That's what happened to the Samsung documentation for example. So whenever vendors are coming in and I meet them, I mention how happy we are about Intel releasing documentation under Creative Commons. More chip vendors should adopt this, and I hope Intel itself eventually will release all their documentation under a Creative Commons license, not turn back... Best Regards, thanks for your help in pointing us at interesting chips! Wolfgang On Aug 14, 2008, at 8:00 AM, Jeffery Davis wrote: > Is there any possibility a future model could incorporate the Intel > Atom? They're launching dual-core > models soon at around $43. Battery life would probably be somewhat > less > than it would continuing with ARM, though. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
On Wed, Aug 13, 2008 at 5:00 PM, Jeffery Davis <[EMAIL PROTECTED]> wrote: > Is there any possibility a future model could incorporate the Intel > Atom? They're launching dual-core > models soon at around $43. Battery life would probably be somewhat less > than it would continuing with ARM, though. http://en.wikipedia.org/wiki/Intel_atom They take from 0.65-4 W depending on which generation, and speed. I don't really see the point, why you'd want an x86 architecture on a phone. (It's basically the original Pentium, miniaturized and incorporating their latest manufacturing process innovations to make it low-power.) Just that there are a lot of x86 binaries (and OSes) you could run unmodified, but compiling for ARM isn't so bad, and ARM has better performance-per-watt and lower-power sleep modes, right? I imagine if we see these in phones, they will be large, loaded with "features" (like some of the larger Symbian models), either with lousy battery life or giant batteries, and maybe the point will be to run a PC-like version of Windows on them rather than just Windows Mobile. (Traveling execs think they gotta have their Excel spreadsheets on the go) I would like to be pleasantly surprised though, of course. A monopoly across most forms of computing would be really bad for the market, so I wouldn't want to help Intel achieve that. But maybe they will spur the competition to take ARM to the next level. (multi-core, smaller, and faster) $43 is not cheap either. Probably several times what the Freerunner's processor costs. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
On Wed, Aug 13, 2008 at 8:55 PM, Brad Midgley <[EMAIL PROTECTED]> wrote: > I've heard the support chips for atom have not been optimized for > saving power yet, so it may be another generation before atom + > chipset + solid state drive will be within any kind of reasonable > power budget for a handheld. Yeah no kidding... http://www.pcper.com/article.php?aid=597&type=expert&pid=8 See how the "entire system" power is 60 watts max, and doesn't vary much with the load? and here: http://www.pcper.com/article.php?aid=597&type=expert&pid=2 funny how the chipset has a big heatsink with a fan, while the processor has a small heatsink and no fan. :-) At least they are competing favorably with VIA for the mini-ITX boards though. > If they haven't already, they also need to engineer an instant wakeup > (acpi suspend/resume is abysmal) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intel Atom
Hey I've heard the support chips for atom have not been optimized for saving power yet, so it may be another generation before atom + chipset + solid state drive will be within any kind of reasonable power budget for a handheld. If they haven't already, they also need to engineer an instant wakeup (acpi suspend/resume is abysmal) Brad On Wed, Aug 13, 2008 at 6:00 PM, Jeffery Davis <[EMAIL PROTECTED]> wrote: > Is there any possibility a future model could incorporate the Intel > Atom? They're launching dual-core > models soon at around $43. Battery life would probably be somewhat less > than it would continuing with ARM, though. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Brad ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Qualcomm Snapdragon? (Re: Intel Atom )
What about the QC Snapdragon? Technical Features * 1GHz CPU * 600MHz DSP * Support for Linux® and Windows Mobile® * WWAN, Wi-Fi and Bluetooth connectivity * Seventh-generation gpsOne® engine for Standalone-GPS and Assisted-GPS modes, as well as gpsOneXTRATM Assistance * High definition video decode (720P) * 3D graphics with up to 22M triangles/sec and 133M 3D pixels/sec * High resolution XGA display support * 12-megapixel camera * Support for multiple video codecs * Audio codecs: (AAC+, eAAC+, AMR, FR, EFR, HR, WB-AMR, G.729a, G.711 , AAC stereo encode) * Support for Broadcast TV (MediaFLOTM , DVB-H and ISDB-T) * Fully tested, highly-integrated solution including baseband, software, RF, PMIC, Bluetooth, Broadcast & Wi-Fi *Whish list* Regards, ==Original message text=== On Wed, 13 Aug 2008 17:00:37 PDT Jeffery Davis wrote: Is there any possibility a future model could incorporate the Intel Atom? They're launching dual-core models soon at around $43. Battery life would probably be somewhat less than it would continuing with ARM, though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ===End of original message text=== Urivan A. Flores Saaib CiberLinux Networking Email: [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Intel Atom
Is there any possibility a future model could incorporate the Intel Atom? They're launching dual-core models soon at around $43. Battery life would probably be somewhat less than it would continuing with ARM, though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
