On Sat, Aug 13, 2011 at 5:58 PM, Gordan Bobic <gor...@bobich.net> wrote: > On 08/13/2011 02:46 PM, Luke Kenneth Casson Leighton wrote:
>> ok, right. continuing on the discussion of upcoming and/or available >> Cortex A9 systems, i heard back from one of the CPU manufacturers >> (can't say which one), and they are sampling a new CPU next month. >> rough spec: >> >> * Single-Core Cortex A9, 1ghz >> * MALI 400MP 3D >> * SATA-II >> would anybody else be interested to see a small panda-like board (4in >> x 3in or so) or other type of board be brought into existence based >> around this CPU? > > Depends on the cost. Freescale are pretty competitive in this arena with > iMX53. yeah. >> if so, what would you be prepared to do to make that happen and, >> also, what retail price would you be prepared to pay for it? > > Based on the competition maybe $170 for a 2GB one if it has ECC RAM. ok - good to know. >> bear in mind that the CPU's manufacturer has: >> * a general understanding of and respect for free software licenses >> including the GPL. > > What about GPU drivers supporting all the recent Xorg ABIs? I'm not an > OSS faschist who demans everyting be OSS - I am prepred to overlook the > OSS-ness of drivers and detailed documentedness of the GPU if the > drivers are of decent quality, feature-complete and continuously supported. it's MALI 400MP-based. the git repository with the linux kernel already has the mali "shim" linux kernel driver added: that means that the libGLES.so.2 proprietary "system library" should work, and the xorg x11 driver just happily sit on top of that. i don't forsee any problems, but at some point in the next few days/weeks i'm likely to have to test this out (using a demo unit which has the precursor processor in it). it's currently all running android so i'll have to hack together a debian armhf for it. deep joy. >> they also have a "system library" for the on-board Video CODEC DSP, >> which those who understand the subtleties of the GPL will appreciate >> qualifies for an exemption under the GPL, even though it's >> proprietary. they've released an example application which utilises >> libffmpeg (enhancements to use their "system library" have already >> been made) and is a working video player. >> >> for the freedombox to fulfil its sponsor commitments (bearing in mind, >> as we know, the freedombox project is not a hardware project despite >> the word "box" being in the name of the project but they still have to >> deliver a number of actual physical boxes to the pledgeware sponsors), >> i'd say that this CPU and the fact that its manufacturer respects the >> GPL fits the requirements far better than the chosen marvell-based >> plug computer. > > That would depend on the quality of the current drivers/libraries that > aren't OSS and the ongoing support for them. yeah - proprietary's a bitch, whichever way you look at it. you wouldn't believe the fun and games i'm hearing about how these SoC vendors are having a blast with adobe flash... they have to wait in line for adobe to bother to compile up flash... with *their* proprietary hardware video extension libraries! what a hoot. anyway, leaving that aside: there are two areas of stupidity^H^H^H^H^H^Hproprietary. a) hardware-accelerated CODEC library b) MALI-400MP. the first: well... you just have to trust them. and, once you've seen a lowly single-core processor smoke a dual-core intel processor at 1080p30 video playback, you've seen it all. it works, or it doesn't. and, if it works, it will _stay_ working. the second: you have to trust and put your faith in ARM (with their stupid deal with MediaTek). Hallelujah, brothers: _every_ CPU manufacturer using MALI is in the same boat. so that means Samsung Enyxos, Telechips, AMLogic - everybody. bottom line: it's not a nice situation, but tough titty, we have to keep the pressure up. >> perhaps the freedombox project might like, if nothing else, to use >> this CPU as leverage to accelerate marvell out of their self-imposed >> stupor by threatening to pull the plug (ha ha) if they don't get with >> the C21st? >> >> please bear in mind that there is a window of opportunity lasting a >> couple of weeks in which i can potentially persuade the CPU designer >> to come up with a demo / engineering board that would actually be a >> useful saleable product in its own right... >> >> ... and that i can *only* do that if there is a demonstrable need for such. > > The problem is that this board would be in direct competition with this: > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB no it's not. he says... *reviews spec*... yes it is! :) that has a lovely SATA interface as well. and 10/100 ethernet. and, freescale are actually on the ball these days in terms of free software support etc. [ um... freedombox people... tell me... why was the shitty little NDA-loving armv5 marvell sheeva guwwu pwug chosen over the freedom-respecting really rather dishy little IMX53QSB? i realise it's good to break marvell of their paranoia habit but even so... ] > It does have an advantage in terms of A9 vs A8 and ECC, though. yes. even with the linaro improvements to gcc i'd say that the A9 still is a step up (superscalar out-of-order instruction execution). >> so, if you would like an affordable 1ghz Cortex A9 >> panda/beagle/imx53qsb-esque/plug-computer board with 1 or even 2gb of >> DDR3 ECC RAM, with SATA-II and 10/100 Ethernet as well as the usual >> other interfaces including some GPIO pins, *and* where the usual >> battle with the CPU manufacturer over GPL violations and NDAs has >> completely gone, now is the time to speak up and say so. > > I would love to see this succeed - ARM boards with more RAM and more > importantly ECC RAM is something we definitely need in this arena. > Unfortunately, I just committed to getting a load of Freescale boards of > similar spec so I won't be needing any more for a long time to come. *shrug* ah well can't win 'em all. so, you _would_ be in... but you personally don't need them :) and, by the time you do, things will have moved on. ok - anyone else? l. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/capweedyt_vo2rnuf00yade4zfec_idc5ooxfwfrtytz7yfm...@mail.gmail.com
