folks, hi,
i'm contacting people on all of the ARM linux distribution lists to find out if anyone is interested in bringing about the creation of a decent, useful and useable ARM-based Laptop. i've been researching CPUs and how to go about this with a minimum of risk and cost, learning from the experiences of the openpandora for example. all of the enquiries that i've made, for about a year, all point towards a minimum spec of at least a 1ghz CPU, 1gb of RAM and a 12in screen (below those specs is too little, and above them is too costly). does such a machine exist? in one word: no. there are plenty of machines with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the AlwaysInnovating Touchbook) - i wish them every success in their niche markets that are catered for by 1024x600 screens.
for everyone else, who wants to see full documents and full web pages *without* having to press page-up, page-down, there literally is not a single ARM-based (or MIPS-based) product in existence, commercially available, anywhere in the world, despite a lot of talk from ARM, and also from the major ARM licensees, and despite the production cost of ARM-based and MIPS-based laptops being lower than that of an equivalent intel-based system.
so the question i have, for the people on this list is: given that nobody else is taking any initiative, would _you_ like to be part of a project that takes the initiative to create a low-cost, high-end ARM-based laptop? like the OpenPandora, except... done with far less risk and a lot less cost. one absolute key part in reducing risk and cost is to utilise existing casework from a no-brand OEM laptop. all that's then required is to create the motherboard to fit. more info here:
a rough guide i've received from a chinese embedded systems designer is that a design using a Samsung S5PV210 will be about $USD 10,000, and a design using a TI DM3730 or DM3725 will be about $20,000 (TI's CPUs are a bit more complex, and the DM37xx series is newer than Samsung's S5 range)... but that's *it*. that's all it costs, to create the motherboard for fitting into an existing 12in laptop chassis. excluding a DVD or Hard Drive, the BOM (Bill of Materials) will come to somewhere around $150, which translates loosely into $240 to $300 after tax, customs, shipping etc. etc.
i'm still investigating ways to get that price down even further, and i'm really really interested to hear from people who may know of other CPUs. i've just heard today about the ZMS-08 for example, and creativelabs have a SoM (system-on-module) which sounds like a perfect fit: the only bug-bear being the proprietary libraries and creativelab's fear over being swamped by developer wannabes asking for help on how to program one of the most complex Cell Processor Units in existence outside of IBM's and other obscure labs. the proprietary libraries aren't so much the problem as the lack of documentation on the Cell Processor.
so - please do discuss amongst yourselves, or feel free to contact me directly. i'm maintaining a list of links to all the other forums this is going out on, at the bottom of http://lkcl.net/laptop.html - if you would like to recommend an alternative CPU please do review and/or edit http://libreplanet.org/wiki/Group:Hardware/Processors first (either the page itself or the discussion page).
l.
On 31/01/2011 21:51, Luke Kenneth Casson Leighton wrote:
folks, hi,
i'm contacting people on all of the ARM linux distribution lists to find out if anyone is interested in bringing about the creation of a decent, useful and useable ARM-based Laptop. i've been researching CPUs and how to go about this with a minimum of risk and cost, learning from the experiences of the openpandora for example. all of the enquiries that i've made, for about a year, all point towards a minimum spec of at least a 1ghz CPU, 1gb of RAM and a 12in screen (below those specs is too little, and above them is too costly). does such a machine exist? in one word: no. there are plenty of machines with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the AlwaysInnovating Touchbook) - i wish them every success in their niche markets that are catered for by 1024x600 screens.
Genesi Efika MX can take a 1280x720 screen. I've had Genesi confirm this and I'll be fitting it as soon as my Efika MX is back (sent off for a repair).
for everyone else, who wants to see full documents and full web pages *without* having to press page-up, page-down, there literally is not a single ARM-based (or MIPS-based) product in existence, commercially available, anywhere in the world, despite a lot of talk from ARM, and also from the major ARM licensees, and despite the production cost of ARM-based and MIPS-based laptops being lower than that of an equivalent intel-based system.
You'd be forgiven for not noticing the difference. Genesi Efika MX and Toshiba AC100 both cost me as much as a similarly specced Atom netbook. They just have 2-4x the battery life and 1/2 the weight and thickness, no moving parts (especially fans), etc.
so the question i have, for the people on this list is: given that nobody else is taking any initiative, would _you_ like to be part of a project that takes the initiative to create a low-cost, high-end ARM-based laptop? like the OpenPandora, except... done with far less risk and a lot less cost. one absolute key part in reducing risk and cost is to utilise existing casework from a no-brand OEM laptop. all that's then required is to create the motherboard to fit. more info here:
a rough guide i've received from a chinese embedded systems designer is that a design using a Samsung S5PV210 will be about $USD 10,000, and a design using a TI DM3730 or DM3725 will be about $20,000 (TI's CPUs are a bit more complex, and the DM37xx series is newer than Samsung's S5 range)... but that's *it*. that's all it costs, to create the motherboard for fitting into an existing 12in laptop chassis. excluding a DVD or Hard Drive, the BOM (Bill of Materials) will come to somewhere around $150, which translates loosely into $240 to $300 after tax, customs, shipping etc. etc.
i'm still investigating ways to get that price down even further, and i'm really really interested to hear from people who may know of other CPUs. i've just heard today about the ZMS-08 for example, and creativelabs have a SoM (system-on-module) which sounds like a perfect fit: the only bug-bear being the proprietary libraries and creativelab's fear over being swamped by developer wannabes asking for help on how to program one of the most complex Cell Processor Units in existence outside of IBM's and other obscure labs. the proprietary libraries aren't so much the problem as the lack of documentation on the Cell Processor.
so - please do discuss amongst yourselves, or feel free to contact me directly. i'm maintaining a list of links to all the other forums this is going out on, at the bottom of http://lkcl.net/laptop.html - if you would like to recommend an alternative CPU please do review and/or edit http://libreplanet.org/wiki/Group:Hardware/Processors first (either the page itself or the discussion page).
Funnily enough, I was thinking about something very similar to this just yesterday. My thoughts are as follows:
- Chassis I was was actually pondering using an existing Clevo chassis. I thought about using an M860TU because that has a 1920x1200 (15.4in) screen available, but this is unfortunately only available with a fluorescent backlight. That means inverters for the backlight and high power consumption. So now I am pondering using a slightly newer yet very similar W860CU. That is available with a 1920x1080 LED backlit panel (15.6in). It wouldn't make much sense to use a higher drain screen when low power is a key part of the appeal.
Looking at my M860TU, any suitably small motherboard could be made to fit with a bit of cutting and gluing, and I expect a W860CU would be similar. There is loads of space available in these machines, and they were designed to be easy to work on rather than compact. This makes them lend themselves well to prototyping.
- Motherboard I cannot emphasise enough that the key here is to get something that is already well supported by the: 1) manufacturer 2) community
That pretty much rules out the Nvidia Tegra. Shame, really, it had the potential to be good, but nvidia are too jelous about their drivers to be worth bothering with, and their support isn't good enough to offset that as soon as you are off the straight and narrow.
The closest I have been able to get to finding a decent solution is the Pandaboard (OMAP4 - Cortex A9 / PowerVR SGX). It has a PowerVR GPU which is reasonably well understood, there is working XV video acceleration, and decently working OpenGL ES drivers. With some luck we might get full OpenGL drivers for it, too, since it is a GPU core virtually identical to what Intel use (Intel GMA). With Tegra we are unlikely to _ever_ get full fat OpenGL, and decent driver support for Linux will probably take years.
The one thing that is currently missing is a LVDS module, but somebody on the list was recently saying that a HDMI->LVDS module will be available imminently. That pretty much leaves just the battery charging circuit and the power brick, which can hopefully be integrated into all that space that will be empty in the machine without a big fat motherboard, heatsinks, fans, etc, so the power lead can just be a simple 2-wire mains one. Nice and portable (well as portable as a W860CU).
Now, I recognize that 1920x1080 isn't what most people are expecting or wanting out of an ARM laptop, and neither is a 15.6in size, but I like my pixel density and pixel count. 13in would be better, but that panel is rare and expensive and the only chassis that takes it is the Sony Vaio Z (at £2500, not even worth considering).
Now, obviously, even made using off-the-shelf-ish parts like this (you'll have to work hard to get a Clevo chassis without a motherboard), but the costs would likely be in the 3-4x what you were hoping for.
Pandaboard is $174. A Clevo W860CU is not far from 10x that (OK, that includes the motherboard, CPU, an expensive GPU, RAM, disk, etc, but it'd be difficult to persuade a distributor to sell you a bare chassis with a battery and screen).
The upshot, however, is that you would likely get 20+ hours of battery life out of it.
The other thing I consider to be a big problem is the amount of RAM available. Pandaboard comes with 1GB of RAM, which is on the small size if we're really serious about this. I'd like to see at least 2GB, but I'm not sure if this is viable with a Pandaboard. I haven't seen any ARM boards with > 1GB of RAM:
Genesi Efika MX: 512MB Toshiba AC100: 512MB Sheevaplug: 512MB
Pandaboard: 1GB Compulab offerings top out at 1GB
Ideally what I want is something like a Pandaboard with a DDR3 SODIMM.
But if something like this were available off the shelf, and based on something very well supported by the community already, I'd happily pay a considerable premium for it.
Gordan
On Mon, Jan 31, 2011 at 10:25 PM, Gordan Bobic gordan@bobich.net wrote:
with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the AlwaysInnovating Touchbook) - i wish them every success in their niche markets that are catered for by 1024x600 screens.
Genesi Efika MX can take a 1280x720 screen.
really? hoooraaay! wow, wow, and they cost about... $50 instead of $30. i so don't understand why these aren't fitted as standard. still, bless 'em. 10in LCD, 800mhz CPU and 512mb RAM - it's... pushing your luck as a "main development machine"...
for everyone else, who wants to see full documents and full web pages *without* having to press page-up, page-down, there literally is not a single ARM-based (or MIPS-based) product in existence, commercially available, anywhere in the world, despite a lot of talk from ARM, and also from the major ARM licensees, and despite the production cost of ARM-based and MIPS-based laptops being lower than that of an equivalent intel-based system.
You'd be forgiven for not noticing the difference. Genesi Efika MX and Toshiba AC100 both cost me as much as a similarly specced Atom netbook. They just have 2-4x the battery life and 1/2 the weight and thickness, no moving parts (especially fans), etc.
i know, damnit!!! and the OLPC XO-1.75, which admittedly uses a 1.2ghz marvell "superscalar" CPU (which makes a biiig difference), reports are in that running Fedora it *outperforms* an intel atom laptop.
so - please do discuss amongst yourselves, or feel free to contact me directly. i'm maintaining a list of links to all the other forums this is going out on, at the bottom of http://lkcl.net/laptop.html - if you would like to recommend an alternative CPU please do review and/or edit http://libreplanet.org/wiki/Group:Hardware/Processors first (either the page itself or the discussion page).
Funnily enough, I was thinking about something very similar to this just yesterday. My thoughts are as follows:
- Chassis
I was was actually pondering using an existing Clevo chassis. I thought about using an M860TU because that has a 1920x1200 (15.4in) screen available, but this is unfortunately only available with a fluorescent backlight. That means inverters for the backlight and high power consumption.
yyep.
So now I am pondering using a slightly newer yet very similar W860CU. That is available with a 1920x1080 LED backlit panel (15.6in). It wouldn't make much sense to use a higher drain screen when low power is a key part of the appeal.
yes. that will mean that it probably requires a 3x LVDS IC [big, fat cable, at least 40 wires] do you have a datasheet around? unless it runs at 30hz refresh rate, in which case they *might* have only the one LVDS channel... yep, need a datasheet on the LCD panel.
Looking at my M860TU, any suitably small motherboard could be made to fit with a bit of cutting and gluing, and I expect a W860CU would be similar. There is loads of space available in these machines, and they were designed to be easy to work on rather than compact. This makes them lend themselves well to prototyping.
i'm counting on it :)
- Motherboard
I cannot emphasise enough that the key here is to get something that is already well supported by the:
- manufacturer
- community
That pretty much rules out the Nvidia Tegra.
yyep.
Shame, really, it had the potential to be good, but nvidia are too jelous about their drivers to be worth bothering with, and their support isn't good enough to offset that as soon as you are off the straight and narrow.
The closest I have been able to get to finding a decent solution is the Pandaboard (OMAP4 - Cortex A9 / PowerVR SGX). It has a PowerVR GPU which is reasonably well understood, there is working XV video acceleration, and decently working OpenGL ES drivers.
_proprietary_ OpenGL drivers.
With some luck we might get full OpenGL drivers for it, too, since it is a GPU core virtually identical to what Intel use (Intel GMA).
ok - i've been researching the SGX hardware, and it is... complex. i've put in a proposal for funding, here: http://tree.celinuxforum.org/pipermail/celinux-dev/2011-January/002107.html
and i've been working to get SGX added to the GNU "High Priority" Project list: http://www.fsf.org/campaigns/priority-projects/index_html/#powervr
ok, unfortunately, there are two other things that stop the OMAP4 from being used (and the Pandaboard). the first is that you have to understand that 90% of TI's revenue comes from the military (radar, sonar) and this helps explain the rather top-heavy Free Software support as well as the high pricing. the second is that the OMAP4's DSP speed and capability has hit some sort of threshold which has resulted in a BXPA "weapons" classification being slapped on it. thus, even to get samples shipped outside of the U.S. or Europe now requires permission - and a license - on an individual case-by-case basis, from the U.S. or U.K government.
the second thing is that the Pandaboard (and the Beagleboard-XM) use "Package-on-Package" RAM. even TI's own documentation state that the yields on one memory supplier's 512mb POP RAM have been so rubbish that they got TWO percent success rate. not to mention the insane cost of these high-density RAM chips.
so, yes, you _could_ base a design around the (vanilla) BBxM or even the Pandaboard, but... yyeah :)
sorry, gordan, i really _have_ been on this for months :) the S5PV210 is the lowest "from-scratch" development cost found so far (ok, not entirely from-scratch - it's actually adaptation of an existing, proven and well-understood 2009 CPU), and the next suitable one is the DM3730 / 3725. which, because that's a 2010 CPU, is less well-understood so the costs are double.
now i _have_ been advised of another two CPUs - one is the nusmart 2816 and the other is the ziilabs ZMS-08. the nice thing about the ZMS-08 is that it is *already* available in a "system-on-module" format: http://www.ziilabs.com/products/platforms/zms08som.aspx
use of this module would mean zero SO-DIMM development costs, meaning that all that would be required would be a motherboard, and that's only about $2k-$3k!
i'm investigating its price, availability and Free-Software compatibility. it has a Cell Processor (8x8 vector processing unit) and ziilabs apparently are scared witless of being overwhelmed with whining eemo wannabe-developer support calls if they release the docs on its instruction set. this is based on their experience, apparently, of commercial companies (asian factories) being completely incapable of programming it. do the math on that logic, and you have to laugh, really, but i _do_ need to come up with a reassuring argument.
The one thing that is currently missing is a LVDS module, but somebody on the list was recently saying that a HDMI->LVDS module will be available imminently. That pretty much leaves just the battery charging circuit
and Audio IC, LCD brightness control, USB Hub and Ethernet end-point IC (usually). but yes, pretty basic, and costing about... ok, it's really hard to create an estimate that goes over $USD 15 in components.
and the power brick, which can hopefully be integrated into all that space that will be empty in the machine without a big fat motherboard, heatsinks, fans, etc, so the power lead can just be a simple 2-wire mains one. Nice and portable (well as portable as a W860CU).
:)
Now, I recognize that 1920x1080 isn't what most people are expecting or wanting out of an ARM laptop, and neither is a 15.6in size, but I like my pixel density and pixel count. 13in would be better, but that panel is rare and expensive and the only chassis that takes it is the Sony Vaio Z (at £2500, not even worth considering).
Now, obviously, even made using off-the-shelf-ish parts like this (you'll have to work hard to get a Clevo chassis without a motherboard),
yes :) it would mean negotiating with clevo.
but the costs would likely be in the 3-4x what you were hoping for.
Pandaboard is $174. A Clevo W860CU is not far from 10x that (OK, that includes the motherboard, CPU, an expensive GPU, RAM, disk, etc, but it'd be difficult to persuade a distributor to sell you a bare chassis with a battery and screen).
The upshot, however, is that you would likely get 20+ hours of battery life out of it.
ahh, it depends on the power
The other thing I consider to be a big problem is the amount of RAM available. Pandaboard comes with 1GB of RAM, which is on the small size if we're really serious about this. I'd like to see at least 2GB, but I'm not sure if this is viable with a Pandaboard. I haven't seen any ARM boards with
1GB of RAM:
Genesi Efika MX: 512MB Toshiba AC100: 512MB Sheevaplug: 512MB
Pandaboard: 1GB
POP - this will be eeexpensiiive.
Compulab offerings top out at 1GB
ooo goood.
Ideally what I want is something like a Pandaboard with a DDR3 SODIMM.
*sigh* yehhhs... but then that means that the motherboard itself needs to be a 6-layer or even a 10-layer board, as the CPU itself needs to be on the motherboard. and _that_ means you're now into $40k development costs (of months). if the CPU itself is on the SO-DIMM (System-on-Module) and you can find one that suits already, then the dev costs are $2-$3k (and only a couple of weeks). that's a _big_ difference.
But if something like this were available off the shelf, and based on something very well supported by the community already, I'd happily pay a considerable premium for it.
ok. the plan is to create at least a "generic" motherboard, approx 7cm x 9cm, with flying leads that can go to the connectors, regardless of how large the case.
that way it would be kiiinda possible to fulfil other laptop specs, but the kick-in-the-teeth there is the LVDS and LCD power requirements. the connectors vary *radically*. i know of an IC that can do up to 30 volts (funnily enough the one used by the ODroid from hardkernel.com) but there do exist LCD screens, esp. the larger ones, that require more for their LED backlights (36v).
it's tricky! :)
but, yeah, the aim is to fulfil the largest number of peoples' needs first (weight of numbers) and then branch out from there.
l.
Luke Kenneth Casson Leighton wrote:
On Mon, Jan 31, 2011 at 10:25 PM, Gordan Bobic gordan@bobich.net wrote:
with 1024x600 screens (the toshiba AC100, the Genesi-USA Ekiga and the AlwaysInnovating Touchbook) - i wish them every success in their niche markets that are catered for by 1024x600 screens.
Genesi Efika MX can take a 1280x720 screen.
really? hoooraaay! wow, wow, and they cost about... $50 instead of $30. i so don't understand why these aren't fitted as standard. still, bless 'em. 10in LCD, 800mhz CPU and 512mb RAM - it's... pushing your luck as a "main development machine"...
I, too, am puzzled by the choice of a low res screen. I suspect the reasons are:
1) $20 extra profit per machine is noticeable and/or reduced sales from a price tag of an extra $20 would be noticeable. The Efika MX Smartbook is already $350 which is quite expensive for a netbook.
2) Most people (the average users - I am not talking about the present audience of geeks who know what they are doing) simply expect a netbook to have a 9-10in panel that is 1024x600. Not out of technical merit, but because that's what all the ones you'll see at a shop will have.
As for "main development machine" - even 1366x768 would be pushing it for development. I wouldn't consider anything lower res than 1920x1080 to be suitable for a dev machine nowdays.
My main work laptop is 2048x1536 (homebrew Thinkpad with a non-standard screen, google about it to get details on what to do and how if you're interested), but that panel is out of production and hard to get hold of at the moment, and it's fluorescent backlit, which means a >= 15W power budget just for the screen. :'( Then again, 15W is less than 1/2 of the power draw at idle when you have the rest of a Core2 system to keep powered up.
for everyone else, who wants to see full documents and full web pages *without* having to press page-up, page-down, there literally is not a single ARM-based (or MIPS-based) product in existence, commercially available, anywhere in the world, despite a lot of talk from ARM, and also from the major ARM licensees, and despite the production cost of ARM-based and MIPS-based laptops being lower than that of an equivalent intel-based system.
You'd be forgiven for not noticing the difference. Genesi Efika MX and Toshiba AC100 both cost me as much as a similarly specced Atom netbook. They just have 2-4x the battery life and 1/2 the weight and thickness, no moving parts (especially fans), etc.
i know, damnit!!! and the OLPC XO-1.75, which admittedly uses a 1.2ghz marvell "superscalar" CPU (which makes a biiig difference), reports are in that running Fedora it *outperforms* an intel atom laptop.
Yeah, the Marvell Armada (I bet Intel are kicking themselves for having sold their XScale ARM business to Marvell only a few years ago) is pretty good. My 1.2GHz Sheevaplug (Marvell Kirkwood) gives my Atom N450 servers a serious run for their money at 1/4 the power budget.
So now I am pondering using a slightly newer yet very similar W860CU. That is available with a 1920x1080 LED backlit panel (15.6in). It wouldn't make much sense to use a higher drain screen when low power is a key part of the appeal.
yes. that will mean that it probably requires a 3x LVDS IC [big, fat cable, at least 40 wires] do you have a datasheet around? unless it runs at 30hz refresh rate, in which case they *might* have only the one LVDS channel... yep, need a datasheet on the LCD panel.
I suspect (it's just a guess, but an educated one) the panel they use is an AUO (AU Optronics) B156HW01 or B156HW02. There are almost certainly several interchangeable variants of each, with possibly slightly different LVDS plug locations.
Here is a spec sheet for one of the variants: www.yslcd.com.tw/docs/product/B156HW01%20V.3.pdf
[Clevo W860CU chassis: good] [Tegra bad: bad]
The closest I have been able to get to finding a decent solution is the Pandaboard (OMAP4 - Cortex A9 / PowerVR SGX). It has a PowerVR GPU which is reasonably well understood, there is working XV video acceleration, and decently working OpenGL ES drivers.
_proprietary_ OpenGL drivers.
Which is better than _no_ OpenGL drivers (or OpenGL capability). Having said that, I don't actually care too much if there is working 3D acceleration, so OpenGL is definitely optional. But if there is OpenGL it should be the real thing, not ES. 2D acceleration with XV should be perfectly sufficient for the sort of thing we are discussing here.
With some luck we might get full OpenGL drivers for it, too, since it is a GPU core virtually identical to what Intel use (Intel GMA).
ok - i've been researching the SGX hardware, and it is... complex. i've put in a proposal for funding, here: http://tree.celinuxforum.org/pipermail/celinux-dev/2011-January/002107.html
Excellent thread, thank you.
One thing I felt I should mention re: what is said in the linked thread - the Marvell ARMs aren't as good per watt as Cortex A9 based designs. I measured my AC100 (battery removed) at 6W at the wall plug, with no power management enabled. That includes a power brick (likely ~80% efficient), so let's say 5W. The Samsung panel in it is specced to draw about 3W, so call it an even 2W, for the Tegra 2 which is a dual core Cortex A9 with an nvidia GPU, RAM, etc.
My Sheevaplug (Marvell Kirkwood, no screen) draws 7W.
and i've been working to get SGX added to the GNU "High Priority" Project list: http://www.fsf.org/campaigns/priority-projects/index_html/#powervr
Good luck. My hardware reverse engineering experience is just about 100% non-existant, so I don't think I can help directly.
ok, unfortunately, there are two other things that stop the OMAP4 from being used (and the Pandaboard). the first is that you have to understand that 90% of TI's revenue comes from the military (radar, sonar) and this helps explain the rather top-heavy Free Software support as well as the high pricing. the second is that the OMAP4's DSP speed and capability has hit some sort of threshold which has resulted in a BXPA "weapons" classification being slapped on it. thus, even to get samples shipped outside of the U.S. or Europe now requires permission - and a license - on an individual case-by-case basis, from the U.S. or U.K government.
Really? I had no idea. So how does the Pandaboard get around the issue?
the second thing is that the Pandaboard (and the Beagleboard-XM) use "Package-on-Package" RAM. even TI's own documentation state that the yields on one memory supplier's 512mb POP RAM have been so rubbish that they got TWO percent success rate. not to mention the insane cost of these high-density RAM chips.
so, yes, you _could_ base a design around the (vanilla) BBxM or even the Pandaboard, but... yyeah :)
I don't see any downsides of basing it on the Pandaboard, except: 1) Low RAM amount 2) Lack of LVDS module for the next month or three
sorry, gordan, i really _have_ been on this for months :) the S5PV210 is the lowest "from-scratch" development cost found so far (ok, not entirely from-scratch - it's actually adaptation of an existing, proven and well-understood 2009 CPU), and the next suitable one is the DM3730 / 3725. which, because that's a 2010 CPU, is less well-understood so the costs are double.
I think supportability and availablilty should take more precedence than the development costs.
now i _have_ been advised of another two CPUs - one is the nusmart 2816 and the other is the ziilabs ZMS-08. the nice thing about the ZMS-08 is that it is *already* available in a "system-on-module" format: http://www.ziilabs.com/products/platforms/zms08som.aspx
use of this module would mean zero SO-DIMM development costs, meaning that all that would be required would be a motherboard, and that's only about $2k-$3k!
What is the CPU on that? Cortex could mean anything from Cortex M0 to Cortex A9.
And how would the RAM on that get expanded? How much RAM will the CPU support?
i'm investigating its price, availability and Free-Software compatibility. it has a Cell Processor (8x8 vector processing unit) and ziilabs apparently are scared witless of being overwhelmed with whining eemo wannabe-developer support calls if they release the docs on its instruction set. this is based on their experience, apparently, of commercial companies (asian factories) being completely incapable of programming it. do the math on that logic, and you have to laugh, really, but i _do_ need to come up with a reassuring argument.
I don't see anything about a cell vector processor listed in the spec. If it does have it, then that may well be a BAD thing - more transistors means more watts, and the chances of any ARM Linux software using it any time soon is pretty close to 0 (look how much uses SSE properly on x86, and that's been around for over a decade, GCC still can't generate useful SSE code).
I'd stick with the _simplest_ possible Cortex A9 / PowerVR combo available. And I only say PowerVR because I'm not aware of more supportable alternatives at the moment.
Now, I recognize that 1920x1080 isn't what most people are expecting or wanting out of an ARM laptop, and neither is a 15.6in size, but I like my pixel density and pixel count. 13in would be better, but that panel is rare and expensive and the only chassis that takes it is the Sony Vaio Z (at £2500, not even worth considering).
Now, obviously, even made using off-the-shelf-ish parts like this (you'll have to work hard to get a Clevo chassis without a motherboard),
yes :) it would mean negotiating with clevo.
Or paying a small-ish premium for getting a bare-bones system from a reseller, and throwing the mobo away. If you add up what the components cost, the cost of the bare chassis with a mobo is tiny.
but the costs would likely be in the 3-4x what you were hoping for.
Pandaboard is $174. A Clevo W860CU is not far from 10x that (OK, that includes the motherboard, CPU, an expensive GPU, RAM, disk, etc, but it'd be difficult to persuade a distributor to sell you a bare chassis with a battery and screen).
The upshot, however, is that you would likely get 20+ hours of battery life out of it.
ahh, it depends on the power
Sure it does, but we are talking about _maybe_ 5W for the screen and considerably less than that for the rest with a decent choice of CPU/mobo. I'd guess the total would be somewhere around 1/3 of what an Atom N450 netbook requires, and that is as good as it gets for x86.
The other thing I consider to be a big problem is the amount of RAM available. Pandaboard comes with 1GB of RAM, which is on the small size if we're really serious about this. I'd like to see at least 2GB, but I'm not sure if this is viable with a Pandaboard. I haven't seen any ARM boards with
1GB of RAM:
Genesi Efika MX: 512MB Toshiba AC100: 512MB Sheevaplug: 512MB
Pandaboard: 1GB
POP - this will be eeexpensiiive.
$175/board doesn't sound that expensive in the grand scheme of things, unless you are referring to other potential issues (e.g. import/export licencing you mentioned).
Compulab offerings top out at 1GB
ooo goood.
Indeed, but Compulab goods are _expensive_. 2-3x what you'd pay for a Pandaboard.
This may also be of interest: http://www.reghardware.com/2011/01/26/compulab_trim_slice/
Still only 1GB of RAM, though. I wouldn't want to aim for less than 2GB to start with at the very least. And unless there is an _overwhelming_ cost or power consumption argument, the RAM should really be on a DIMM (it's hard to see how that wouldn't be the cheapest solution in the long-run).
Ideally what I want is something like a Pandaboard with a DDR3 SODIMM.
*sigh* yehhhs... but then that means that the motherboard itself needs to be a 6-layer or even a 10-layer board, as the CPU itself needs to be on the motherboard. and _that_ means you're now into $40k development costs (of months). if the CPU itself is on the SO-DIMM (System-on-Module) and you can find one that suits already, then the dev costs are $2-$3k (and only a couple of weeks). that's a _big_ difference.
Agreed, but I don't think it makes sense to even consider this if the SoC module doesn't come with at least 2GB of RAM and Cortex A9 class CPU.
Just out of interest (forgive me if the question is daft, I'm not all that familiar how this segment of the market works) - is there a standard for the way SODIMMs SoC modules are wired up? i.e. would you then be able to replace the SODIMM on this custom mobo with another SODIMM SoC and expect it to "just work" provided all the features are present? I'm guessing the chances of this are less than 0.
But if something like this were available off the shelf, and based on something very well supported by the community already, I'd happily pay a considerable premium for it.
ok. the plan is to create at least a "generic" motherboard, approx 7cm x 9cm, with flying leads that can go to the connectors, regardless of how large the case.
Indeed, this is what I was thinking about with a Pandaboard - have USB (and audio) extension cables going to the case ports if needs be.
that way it would be kiiinda possible to fulfil other laptop specs, but the kick-in-the-teeth there is the LVDS and LCD power requirements. the connectors vary *radically*. i know of an IC that can do up to 30 volts (funnily enough the one used by the ODroid from hardkernel.com) but there do exist LCD screens, esp. the larger ones, that require more for their LED backlights (36v).
it's tricky! :)
A bit of custom circuitry isn't the end of the world if you are shooting for a relatively stationary target. Having said that, it's only a matter of time before laptops go from LED backlit to outright OLED like the current phones, which may require a slight change to the circuitry. This _could_ be pre-empted by making the relevant components modular, of course. But then we could also say the same thing about the SoC module, and the chances are that the new/replacement SoC module would not be compatible.
but, yeah, the aim is to fulfil the largest number of peoples' needs first (weight of numbers) and then branch out from there.
I'm all for a project like this, but I suspect the volume will be quite low. That means high unit cost, and in that case it makes more sense to aim for the high end, since there is a higher chance of being competitive there. It will be easier to come up with a very low power and adequate performance 15.6in 1920x1080 laptop with 20 hours battery life for $1500 than a slightly better 10in 1280x720 laptop that has to be competitive against the $350 offerings.
Having said all that, it may be worthwhile having a word with Genesi. They are probably already working on the next gen of Efika MX. If you can stir up enough interest in something like this (and I would definitely be interested in something like what I've described unless the cost per unit ends up being eyewateringly outrageous), then it would make a some sense to try to get an established manufacturer on-board. Unless you have a very commercial/competitive venture in mind.
Gordan
P.S.
I think we should take this off the list, unless a lot of others here want to partake, since by my reckoning the Fedora related content in this is becoming pretty close to 0.
On Tue, Feb 1, 2011 at 3:29 PM, Gordan Bobic gordan@bobich.net wrote:
I suspect (it's just a guess, but an educated one) the panel they use is an AUO (AU Optronics) B156HW01 or B156HW02. There are almost certainly several interchangeable variants of each, with possibly slightly different LVDS plug locations.
Here is a spec sheet for one of the variants: www.yslcd.com.tw/docs/product/B156HW01%20V.3.pdf
leeme check.. ok, 7-20 volt LED power, that's good: that's quite a common standard. and it's a "double" LVDS, hmm, looks quite straightforward, just double up the LVDS ICs: SN75LVDS83b quantity 2 should do the job. even needs two separate LVDS clocks. so, yeah.
support as well as the high pricing. the second is that the OMAP4's DSP speed and capability has hit some sort of threshold which has resulted in a BXPA "weapons" classification being slapped on it. thus, even to get samples shipped outside of the U.S. or Europe now requires permission - and a license - on an individual case-by-case basis, from the U.S. or U.K government.
Really? I had no idea. So how does the Pandaboard get around the issue?
presumably by being designed in the EU or USA and only sold *to* people in the EU or USA. wouldn't it be a hoot if someone forgot to tell the sales teams that the CPU was export-restricted, and TI got prosecuted :)
so, yes, you _could_ base a design around the (vanilla) BBxM or even the Pandaboard, but... yyeah :)
I don't see any downsides of basing it on the Pandaboard, except:
- Low RAM amount
- Lack of LVDS module for the next month or three
yes. and you'll need a double-LVDS channel for that 1920x1080 LCD.
now i _have_ been advised of another two CPUs - one is the nusmart 2816 and the other is the ziilabs ZMS-08. the nice thing about the ZMS-08 is that it is *already* available in a "system-on-module" format: http://www.ziilabs.com/products/platforms/zms08som.aspx
use of this module would mean zero SO-DIMM development costs, meaning that all that would be required would be a motherboard, and that's only about $2k-$3k!
What is the CPU on that? Cortex could mean anything from Cortex M0 to Cortex A9.
A8.
And how would the RAM on that get expanded? How much RAM will the CPU support?
1gb (A8s support 1gb). the SoM (as it stands) can take 4 micron 2gbit x16 ICs (hynix don't do a 2gbit x16 mobile DDR part).
I don't see anything about a cell vector processor listed in the spec.
no - and the reason for that is precisely because they DO NOT want people ringing up even _asking_ for "free" support as they believe it is a total waste of their time.
their primary customers have been companies who are basically incompetent at software development, and expect to be spoon-fed full solutions, or they will go elsewhere. so creativelabs have developed ready-made (proprietary) OpenGL and MPEG proprietary libraries, and that keeps these drone-clone companies happy.
If it does have it, then that may well be a BAD thing - more transistors means more watts, and the chances of any ARM Linux software using it any time soon is pretty close to 0 (look how much uses SSE properly on x86, and that's been around for over a decade, GCC still can't generate useful SSE code).
I'd stick with the _simplest_ possible Cortex A9 / PowerVR combo available.
there's the pandaboard, and that's... it.
And I only say PowerVR because I'm not aware of more supportable alternatives at the moment.
it's non-free, and... yes, hm.
you're aiming for a market segment a bit higher than i have been planning. not that that rules out covering both, but i have some other markets that can be covered, and if the BOM comes to $300 that means a $600 to $800 price-tag, which is wayy outside of the consumer mass-market price range i'm also looking at.
Pandaboard: 1GB
POP - this will be eeexpensiiive.
$175/board doesn't sound that expensive in the grand scheme of things, unless you are referring to other potential issues (e.g. import/export licencing you mentioned).
i'm thinking and have been planning along the lines of a BOM *under* that cost of $175/board - just for that board!
Just out of interest (forgive me if the question is daft, I'm not all that familiar how this segment of the market works) - is there a standard for the way SODIMMs SoC modules are wired up?
noooo *sigh* :)
i.e. would you then be able to replace the SODIMM on this custom mobo with another SODIMM SoC and expect it to "just work" provided all the features are present? I'm guessing the chances of this are less than 0.
_some_ designers have managed it. cogcomp.com's SoMs are all inter-compatible for example, and directinsight have an AM37xx board that's pin-compatible with their DM37xx board.
I'm all for a project like this, but I suspect the volume will be quite low. That means high unit cost, and in that case it makes more sense to aim for the high end, since there is a higher chance of being competitive there. It will be easier to come up with a very low power and adequate performance 15.6in 1920x1080 laptop with 20 hours battery life for $1500 than a slightly better 10in 1280x720 laptop that has to be competitive against the $350 offerings.
Having said all that, it may be worthwhile having a word with Genesi. They are probably already working on the next gen of Efika MX.
i already asked. they already told me they had made their decisions (for the next generation) and were not in the slightest bit interested in changing their minds to expand the market opportunities for the new product.
If you can stir up enough interest in something like this (and I would definitely be interested in something like what I've described unless the cost per unit ends up being eyewateringly outrageous), then it would make a some sense to try to get an established manufacturer on-board. Unless you have a very commercial/competitive venture in mind.
i do.
also - an established manufacturer is the absolute last thing that's needed. they will add a large markup/premium, apart from anything else. but think about this: ARM CPUs capable of running laptops have been available since early 2009 (and one or two even before that). you'd think that, by now, one of the "established" manufacturers would come up with the goods, neh? it doesn't take 6 months to put a design together if you've got the money, and they've got the money. so where _are_ these magic low-power, lower-cost high-end ARM and MIPS laptops, from the established manufacturers?
look up the pegatron netbook, and also look up IBM's ARM-based "smartbook" (both have that looovely 1024x600 screen). and freescale's smartbook reference design. and several qualcomm-based 1ghz smartbooks. etc. etc. etc. etc. they _just_ aren't delivering the goods, are usually GPL-violating (esp if from S.Asia), and are too expensive. oh, and usually have crap amounts of RAM or crap screen resolutions. dead from the neck up, in other words :)
Gordan
P.S.
I think we should take this off the list, unless a lot of others here want to partake, since by my reckoning the Fedora related content in this is becoming pretty close to 0.
:) feel free to subscribe to the arm-netbook list (cc'd here).
Hi Luke, this is Bill Buck writing you. I am the CEO of Genesi and subscribed to this mailing list. While I have had some contact with Gordon, I have never discussed any of these matters with you. I am certain you are not aware of our detailed plans or how your ambitions can be accommodated as we move ahead.
You are welcome to contact me directly.
Sincerely, Bill
On Tue, Feb 1, 2011 at 11:18 AM, Luke Kenneth Casson Leighton < luke.leighton@gmail.com> wrote:
On Tue, Feb 1, 2011 at 3:29 PM, Gordan Bobic gordan@bobich.net wrote:
I suspect (it's just a guess, but an educated one) the panel they use is
an
AUO (AU Optronics) B156HW01 or B156HW02. There are almost certainly
several
interchangeable variants of each, with possibly slightly different LVDS
plug
locations.
Here is a spec sheet for one of the variants: www.yslcd.com.tw/docs/product/B156HW01%20V.3.pdf
leeme check.. ok, 7-20 volt LED power, that's good: that's quite a common standard. and it's a "double" LVDS, hmm, looks quite straightforward, just double up the LVDS ICs: SN75LVDS83b quantity 2 should do the job. even needs two separate LVDS clocks. so, yeah.
support as well as the high pricing. the second is that the OMAP4's DSP speed and capability has hit some sort of threshold which has resulted in a BXPA "weapons" classification being slapped on it. thus, even to get samples shipped outside of the U.S. or Europe now requires permission - and a license - on an individual case-by-case basis, from the U.S. or U.K government.
Really? I had no idea. So how does the Pandaboard get around the issue?
presumably by being designed in the EU or USA and only sold *to* people in the EU or USA. wouldn't it be a hoot if someone forgot to tell the sales teams that the CPU was export-restricted, and TI got prosecuted :)
so, yes, you _could_ base a design around the (vanilla) BBxM or even the Pandaboard, but... yyeah :)
I don't see any downsides of basing it on the Pandaboard, except:
- Low RAM amount
- Lack of LVDS module for the next month or three
yes. and you'll need a double-LVDS channel for that 1920x1080 LCD.
now i _have_ been advised of another two CPUs - one is the nusmart 2816 and the other is the ziilabs ZMS-08. the nice thing about the ZMS-08 is that it is *already* available in a "system-on-module" format: http://www.ziilabs.com/products/platforms/zms08som.aspx
use of this module would mean zero SO-DIMM development costs, meaning that all that would be required would be a motherboard, and that's only about $2k-$3k!
What is the CPU on that? Cortex could mean anything from Cortex M0 to
Cortex
A9.
A8.
And how would the RAM on that get expanded? How much RAM will the CPU support?
1gb (A8s support 1gb). the SoM (as it stands) can take 4 micron 2gbit x16 ICs (hynix don't do a 2gbit x16 mobile DDR part).
I don't see anything about a cell vector processor listed in the spec.
no - and the reason for that is precisely because they DO NOT want people ringing up even _asking_ for "free" support as they believe it is a total waste of their time.
their primary customers have been companies who are basically incompetent at software development, and expect to be spoon-fed full solutions, or they will go elsewhere. so creativelabs have developed ready-made (proprietary) OpenGL and MPEG proprietary libraries, and that keeps these drone-clone companies happy.
If it does have it, then that may well be a BAD thing - more transistors means more watts, and the chances of any ARM Linux software using it any time
soon
is pretty close to 0 (look how much uses SSE properly on x86, and that's been around for over a decade, GCC still can't generate useful SSE code).
I'd stick with the _simplest_ possible Cortex A9 / PowerVR combo
available.
there's the pandaboard, and that's... it.
And I only say PowerVR because I'm not aware of more supportable alternatives at the moment.
it's non-free, and... yes, hm.
you're aiming for a market segment a bit higher than i have been planning. not that that rules out covering both, but i have some other markets that can be covered, and if the BOM comes to $300 that means a $600 to $800 price-tag, which is wayy outside of the consumer mass-market price range i'm also looking at.
Pandaboard: 1GB
POP - this will be eeexpensiiive.
$175/board doesn't sound that expensive in the grand scheme of things, unless you are referring to other potential issues (e.g. import/export licencing you mentioned).
i'm thinking and have been planning along the lines of a BOM *under* that cost of $175/board - just for that board!
Just out of interest (forgive me if the question is daft, I'm not all
that
familiar how this segment of the market works) - is there a standard for
the
way SODIMMs SoC modules are wired up?
noooo *sigh* :)
i.e. would you then be able to replace the SODIMM on this custom mobo with another SODIMM SoC and expect it to "just work" provided all the features are present? I'm guessing the
chances
of this are less than 0.
_some_ designers have managed it. cogcomp.com's SoMs are all inter-compatible for example, and directinsight have an AM37xx board that's pin-compatible with their DM37xx board.
I'm all for a project like this, but I suspect the volume will be quite
low.
That means high unit cost, and in that case it makes more sense to aim
for
the high end, since there is a higher chance of being competitive there.
It
will be easier to come up with a very low power and adequate performance 15.6in 1920x1080 laptop with 20 hours battery life for $1500 than a
slightly
better 10in 1280x720 laptop that has to be competitive against the $350 offerings.
Having said all that, it may be worthwhile having a word with Genesi.
They
are probably already working on the next gen of Efika MX.
i already asked. they already told me they had made their decisions (for the next generation) and were not in the slightest bit interested in changing their minds to expand the market opportunities for the new product.
If you can stir up enough interest in something like this (and I would definitely be
interested
in something like what I've described unless the cost per unit ends up
being
eyewateringly outrageous), then it would make a some sense to try to get
an
established manufacturer on-board. Unless you have a very commercial/competitive venture in mind.
i do.
also - an established manufacturer is the absolute last thing that's needed. they will add a large markup/premium, apart from anything else. but think about this: ARM CPUs capable of running laptops have been available since early 2009 (and one or two even before that). you'd think that, by now, one of the "established" manufacturers would come up with the goods, neh? it doesn't take 6 months to put a design together if you've got the money, and they've got the money. so where _are_ these magic low-power, lower-cost high-end ARM and MIPS laptops, from the established manufacturers?
look up the pegatron netbook, and also look up IBM's ARM-based "smartbook" (both have that looovely 1024x600 screen). and freescale's smartbook reference design. and several qualcomm-based 1ghz smartbooks. etc. etc. etc. etc. they _just_ aren't delivering the goods, are usually GPL-violating (esp if from S.Asia), and are too expensive. oh, and usually have crap amounts of RAM or crap screen resolutions. dead from the neck up, in other words :)
Gordan
P.S.
I think we should take this off the list, unless a lot of others here
want
to partake, since by my reckoning the Fedora related content in this is becoming pretty close to 0.
:) feel free to subscribe to the arm-netbook list (cc'd here). _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Tue, Feb 1, 2011 at 5:34 PM, Bill Buck bbrv@genesi-tech.com wrote:
Hi Luke, this is Bill Buck writing you. I am the CEO of Genesi and subscribed to this mailing list.
bill - great to hear from you.
While I have had some contact with Gordon, I have never discussed any of these matters with you.
no - ahh you know what? i believe that the conversation i had may have been filtered out before it got to you. hmm.
I am certain you are not aware of our detailed plans or how your ambitions can be accommodated as we move ahead.
that is veeery encouraging.
You are welcome to contact me directly.
most certainly will. _thank_ you bill.
l.
Luke Kenneth Casson Leighton wrote:
[B156HW01: good] [OMAP4 export restrictions]
now i _have_ been advised of another two CPUs - one is the nusmart 2816 and the other is the ziilabs ZMS-08. the nice thing about the ZMS-08 is that it is *already* available in a "system-on-module" format: http://www.ziilabs.com/products/platforms/zms08som.aspx
use of this module would mean zero SO-DIMM development costs, meaning that all that would be required would be a motherboard, and that's only about $2k-$3k!
What is the CPU on that? Cortex could mean anything from Cortex M0 to Cortex A9.
A8.
OK, now I'm _seriously_ wondering why you don't just get an Efika MX and drop a 1280x720 screen into it. That sounds like it'll cover just about all of your requirements: Cortex A8, 1280x720 display. Only 512MB of RAM, but that's the only thing not matching your requirements. Seems a reasonable trade-off for something you can buy off the peg right now vs. 10s of 000s of $ in development costs.
I don't see anything about a cell vector processor listed in the spec.
no - and the reason for that is precisely because they DO NOT want people ringing up even _asking_ for "free" support as they believe it is a total waste of their time.
their primary customers have been companies who are basically incompetent at software development, and expect to be spoon-fed full solutions, or they will go elsewhere. so creativelabs have developed ready-made (proprietary) OpenGL and MPEG proprietary libraries, and that keeps these drone-clone companies happy.
I'd say forget it. This will come to rear it's ugly head as soon as a new version of Xorg is released and the drivers stop working.
And I only say PowerVR because I'm not aware of more supportable alternatives at the moment.
it's non-free, and... yes, hm.
you're aiming for a market segment a bit higher than i have been planning. not that that rules out covering both, but i have some other markets that can be covered, and if the BOM comes to $300 that means a $600 to $800 price-tag, which is wayy outside of the consumer mass-market price range i'm also looking at.
Pandaboard: 1GB
POP - this will be eeexpensiiive.
$175/board doesn't sound that expensive in the grand scheme of things, unless you are referring to other potential issues (e.g. import/export licencing you mentioned).
i'm thinking and have been planning along the lines of a BOM *under* that cost of $175/board - just for that board!
As I said, it sounds like what you're aiming for is already covered by the Efika MX + TFT panel upgrade.
[SODIMM SoC standards or lack thereof]
I'm all for a project like this, but I suspect the volume will be quite low. That means high unit cost, and in that case it makes more sense to aim for the high end, since there is a higher chance of being competitive there. It will be easier to come up with a very low power and adequate performance 15.6in 1920x1080 laptop with 20 hours battery life for $1500 than a slightly better 10in 1280x720 laptop that has to be competitive against the $350 offerings.
Having said all that, it may be worthwhile having a word with Genesi. They are probably already working on the next gen of Efika MX.
i already asked. they already told me they had made their decisions (for the next generation) and were not in the slightest bit interested in changing their minds to expand the market opportunities for the new product.
I'm not yet convinced that your requirements aren't covered well enough by their current product.
[Commercialization]
also - an established manufacturer is the absolute last thing that's needed. they will add a large markup/premium, apart from anything else. but think about this: ARM CPUs capable of running laptops have been available since early 2009 (and one or two even before that). you'd think that, by now, one of the "established" manufacturers would come up with the goods, neh? it doesn't take 6 months to put a design together if you've got the money, and they've got the money. so where _are_ these magic low-power, lower-cost high-end ARM and MIPS laptops, from the established manufacturers?
The problem is two-fold: 1) Lack of perception of a market for the product. There's a lot of money to be made on x86 laptops since the market is so much bigger. More users, more sales, it is as simple as that. For ARM you pretty much have to create the market. To do that, you have to make a product that is sufficiently better to make people say "WTF?! Can that be right?!" to get them to consider moving off the straight and narrow.
2) Lack of software. We all know that Fedora is not yet fit for desktop/laptop use on ARM. It's out of date before it's even released, and the bug count even on x86 is dangerously close to the "enthusiast-only" territory. Where's OpenOffice on Fedora ARM, for example? Why does Firefox crash every few minutes? Where's KDE? Ubuntu is better, but there are still issues, not least of which is driver support.
Now don't get me wrong - I really, REALLY want ARM to succeed in this segment, but it takes a relatively small manufacturer to ring a wake-up call to the big established companies that have responsiveness that broadly resembles steering a supertanker.
look up the pegatron netbook, and also look up IBM's ARM-based "smartbook" (both have that looovely 1024x600 screen). and freescale's smartbook reference design. and several qualcomm-based 1ghz smartbooks. etc. etc. etc. etc. they _just_ aren't delivering the goods, are usually GPL-violating (esp if from S.Asia), and are too expensive. oh, and usually have crap amounts of RAM or crap screen resolutions. dead from the neck up, in other words :)
I was actually really looking forward to the Lenovo Skylight. Was gutted when it got cancelled 6 weeks before it was scheduled to be available for sale.
I think we should take this off the list, unless a lot of others here want to partake, since by my reckoning the Fedora related content in this is becoming pretty close to 0.
:) feel free to subscribe to the arm-netbook list (cc'd here).
Noted.
Gordan
On Tue, Feb 1, 2011 at 6:06 PM, Gordan Bobic gordan@bobich.net wrote:
OK, now I'm _seriously_ wondering why you don't just get an Efika MX and drop a 1280x720 screen into it. That sounds like it'll cover just about all of your requirements: Cortex A8, 1280x720 display. Only 512MB of RAM, but that's the only thing not matching your requirements. Seems a reasonable trade-off for something you can buy off the peg right now vs. 10s of 000s of $ in development costs.
already said - 800mhz CPU. the iMX515 isn't good enough for the _other_ requirements that i have to satisfy (which i haven't mentioned, but involve mass-market volume to get the price down, and require 1080p). the iMX515 only does 720p. i set minimum specs of 1gb RAM, 1ghz Cortex A8 and 1280x800 LCD for good reasons. yes, 1280x720 is _just_ about within that, but the rest of the specs? no.
i don't know for sure but i suspect the iMX515 is a 65nm part, meaning that 800mhz is its limit.
I don't see anything about a cell vector processor listed in the spec.
no - and the reason for that is precisely because they DO NOT want people ringing up even _asking_ for "free" support as they believe it is a total waste of their time.
their primary customers have been companies who are basically incompetent at software development, and expect to be spoon-fed full solutions, or they will go elsewhere. so creativelabs have developed ready-made (proprietary) OpenGL and MPEG proprietary libraries, and that keeps these drone-clone companies happy.
I'd say forget it. This will come to rear it's ugly head as soon as a new version of Xorg is released and the drivers stop working.
tell me about it. it's why i will be speaking to ziilabs to obtain details of the Cell's assembly language etc. i have to come up with a convincing and reassuring strategy as to why they should do exactly that.
As I said, it sounds like what you're aiming for is already covered by the Efika MX + TFT panel upgrade.
no, it's not. you said it yourself: 512mb RAM. as a free software developer, you want 2gb RAM.
there are also other issues, like the fact that freescale are utterly and completely clueless when it comes to linux kernel and other software support. TI is like ... the benchmark gold standard, and whilst freescale don't get an "F" for "Fail" due to GPL violations, doing things like charging $USD 3,000 to get *access* to their iMX535 for example is just asking for trouble.
bless 'em, though. the only thing that freescale got right is the fact that their CPUs are available in 0.8mm BGA pitch, which means that a bog-standard chinese factory stands a hope in hell of assembling them. (below that and you need plasma assembly tooling, to make the damn things stick!)
Now don't get me wrong - I really, REALLY want ARM to succeed in this segment, but it takes a relatively small manufacturer to ring a wake-up call to the big established companies that have responsiveness that broadly resembles steering a supertanker.
we're counting on doing exactly that :)
l.
On 02/01/2011 06:17 PM, Luke Kenneth Casson Leighton wrote:
I don't see anything about a cell vector processor listed in the spec.
no - and the reason for that is precisely because they DO NOT want people ringing up even _asking_ for "free" support as they believe it is a total waste of their time.
their primary customers have been companies who are basically incompetent at software development, and expect to be spoon-fed full solutions, or they will go elsewhere. so creativelabs have developed ready-made (proprietary) OpenGL and MPEG proprietary libraries, and that keeps these drone-clone companies happy.
I'd say forget it. This will come to rear it's ugly head as soon as a new version of Xorg is released and the drivers stop working.
tell me about it. it's why i will be speaking to ziilabs to obtain details of the Cell's assembly language etc. i have to come up with a convincing and reassuring strategy as to why they should do exactly that.
You should also consider that getting FSF drivers for this is of very limited usefulness. This DSP is very proprietary. It would be far more valuable (if more difficult) to get the PowerVR drivers as that would cover the majority of ARM based SoC modules. I don't think it'd be worth the effort, especially for a CPU (A8) that is already on the verge of deprecation.
Gordan
01.02.2011, 05:51, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
01.02.2011, 21:33, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
but, yeah, the aim is to fulfil the largest number of peoples' needs first (weight of numbers) and then branch out from there.
Hi, Luke.
Thank you for the proposal and none the less interesting discussion. It's people like you who actually "get us there" at end, and it's good to know that possible ways are being searched for.
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
The gorgeously-looking Efika MX would fit me almost perfectly if not the soon-deprecating A8 CPU and the plans for a dual-core solution with faster RAM. Plus, taking in mind the early stage of software on ARM and its stability issues and rather a development taste of the hardware, 350 bucks seems above the decent price when you see a 299 competitor on Atom which is, yes, only a 2-hours-on-battery runner that heats like a stove, but hell, it has 1 gig of RAM, a 160 gigs hard drive and takes $my_favorite_distro on-board.
2011/2/2 Misha Shnurapet shnurapet@fedoraproject.org:
01.02.2011, 05:51, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
01.02.2011, 21:33, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
but, yeah, the aim is to fulfil the largest number of peoples' needs first (weight of numbers) and then branch out from there.
Hi, Luke.
Thank you for the proposal and none the less interesting discussion. It's people like you who actually "get us there" at end, and it's good to know that possible ways are being searched for.
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
The Efika MX desktop has 8GB and the Efika MX Smartbook has 16GB of NAND flash connected to the PATA port. Plenty of space. I agree wholeheartedly (see above..) with the video playback thing. A laptop *only* good as a compiler box won't sell.
The gorgeously-looking Efika MX would fit me almost perfectly if not the soon-deprecating A8 CPU and the plans for a dual-core solution with faster RAM. Plus, taking in mind the early stage of software on ARM and its stability issues and rather a development taste of the hardware, 350 bucks seems above the decent price when you see a 299 competitor on Atom which is, yes, only a 2-hours-on-battery runner that heats like a stove, but hell, it has 1 gig of RAM, a 160 gigs hard drive and takes $my_favorite_distro on-board.
The Cortex-A8 is absolutely NOT being deprecated. As for the "early stage of software on ARM", we've been running and shipping a full Linux desktop (GNOME, for all it's worth) for well over a year. I'm not sure what you guys think the state of ARM actually is, if you're basing it on the availability of Fedora.. well, that is Fedora's problem. Other Linux distros (Debian for example) have had no problem running on ARM for almost a decade, using the EABI for nearly 5.
The reason we chose Freescale's i.MX515 is because it had the most mature Cortex-A8 implementation on the market and by far the best integration and featureset. Compared to the other A8 chips at the time - from Samsung or TI - it was head and shoulders above on featureset and performance. As an owner of several varying revisions of Beagleboard, I would say OMAP3 was not the greatest chip to be working with in the world. I like my Beagles but based on experience, I have some doubts that being there first is better than having a mature implementation. Freescale's roadmap is based on waiting until the platform is at a point where it won't cause significant problems to the rollout of the chip - less errata to deal with, ideally less chance of a major automotive customer having cars sold where the dashboard stops working. They'll hit Cortex-A9 at a fairly decent revision, with a very tight integration and an optimized core on an optimized process. TI is trying to be ahead of it's competitors which will result, yet again, in a chip which is going to take 2 years to actually get anywhere in the market.
This is not the Intel/AMD Windows market where every 3 months you need to release something faster, and faster, and faster. To give a very recent and very relevant example, Intel just screwed up their southbridge for the second generation Core i7. It's cost them over half a billion dollars to try and be the latest and greatest and rush chips out. We have had that with chips in the past, trying to be there too fast, and it costs money, and causes strife for customers.
I'll say it again, if you want 2GHz, dual core, 16GB dual-channel DDR3 RAM, 800MHz memory controllers, go buy a PC. You're in the wrong market. Neither ARM nor Freescale or even TI are designing chips for power users; the expected panel resolution is 1024x600. It's very common. Go look at the Blackberry PlayBook, AI TouchBook, etc. - this is the desired form factor, this is what the vendors want, it is what the target users are looking for (and the targets are kids, people who don't do well with computers and are a little bit frightened by a wailing, 17" hulk on their desk just to do word processing and go to Facebook) and the market they are trying to capture is not People Who Compile Software A Lot And Need Tons Of Memory and Enough Processing Power to Make You Dizzy. I call them the Numbers Brigade because the actual usefulness of the device as a holistic computing solution is not relevant to them, it's the bullet points on the processor datasheet compared to another one, and the prospect of a new one coming out soon that will outclass it based entirely on the theoretical math of seeing which number is bigger without taking into account the way the components interact. They are the kind of people who live in a constant state of early adoption and infinite buyer's remorse. While you might think they make up a significant percentage of PC sales through their rampant purchasing of new technology at high prices and low turnaround times, they simply don't.
Maybe when the Cortex-A15 is out and we have ARM servers floating around, the dream of a Power User ARM Smartbook with a huge screen, a ton of RAM and processing power enough to spook a horse will be fulfilled. Good luck waiting for 2015 for that one, in the meantime I guarantee the first usable Cortex-A15 unit on the market will be dual core, less than 1.5GHz, and have an 11" 720p screen on it.
Matt Sealey wrote:
Thank you for the proposal and none the less interesting discussion. It's people like you who actually "get us there" at end, and it's good to know that possible ways are being searched for.
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
The Efika MX desktop has 8GB and the Efika MX Smartbook has 16GB of NAND flash connected to the PATA port. Plenty of space.
That may have been OK by standards of 2-3 years ago. And kudos for including an extra uSD port for extra storage. But performance of _ALL_ SD cards on the market today is appalling. The best ones are ~100x slower than a decent SSD and cost 3x more per GB. As I said before, the only usable SD cards for running the OS from are the SanDisk and Lexar ones, and those are those are about £110 for 32GB vs. £60 for a 40GB Intel X25-V which will annihilate them in performance and is ~20% bigger. With uSD the situation is even worse, the cards are even slower and even more expensive.
The way forward here would be a SATA port. Anything else doesn't cut it in terms of performance, and even on something as low on CPU as an 800MHz A8 still suffers significant slow-down when working off SD cards. This has a massive effect on perceived performance, especially with only 512MB of RAM for caching to cover up the deficiency.
Annoyingly, I've not yet seen a production ARM based netbook with a SATA port.
I agree wholeheartedly (see above..) with the video playback thing. A laptop *only* good as a compiler box won't sell.
Perhaps you can tell us, then, when the Efika MX will have accelerated drivers available? The video poing keeps coming up, but Xorg on my Efika MX is running off raw fbdev on mine and none of the standard acceleration APIs work (e.g. XV).
The gorgeously-looking Efika MX would fit me almost perfectly if not the soon-deprecating A8 CPU and the plans for a dual-core solution with faster RAM. Plus, taking in mind the early stage of software on ARM and its stability issues and rather a development taste of the hardware, 350 bucks seems above the decent price when you see a 299 competitor on Atom which is, yes, only a 2-hours-on-battery runner that heats like a stove, but hell, it has 1 gig of RAM, a 160 gigs hard drive and takes $my_favorite_distro on-board.
The Cortex-A8 is absolutely NOT being deprecated.
Maybe not deprecated in the "out of production sense", but in fairness an 1GHz Tegra 2 blows it away by so much it's not even funny. I think it would be foolish to bother bringing out a new product based on the A8 if it is intended for non-embedded use (i.e. generic laptop/desktop use). I can see that it is overspecified for tablets, phones, and other devices with 800x480 screen that will never need to start up OpenOffice or full fat Firefox, but it doesn't have that much margin for error when it comes to staying on the right side of borderline for a laptop.
But that's just my opinion having extensively used both in the past month or two...
As for the "early
stage of software on ARM", we've been running and shipping a full Linux desktop (GNOME, for all it's worth) for well over a year. I'm not sure what you guys think the state of ARM actually is, if you're basing it on the availability of Fedora.. well, that is Fedora's problem. Other Linux distros (Debian for example) have had no problem running on ARM for almost a decade, using the EABI for nearly 5.
Indeed, I think a lot of us are painfully aware of just how far behind Fedora is at the moment.
The reason we chose Freescale's i.MX515 is because it had the most mature Cortex-A8 implementation on the market and by far the best integration and featureset. Compared to the other A8 chips at the time
- from Samsung or TI - it was head and shoulders above on featureset
and performance. As an owner of several varying revisions of Beagleboard, I would say OMAP3 was not the greatest chip to be working with in the world. I like my Beagles but based on experience, I have some doubts that being there first is better than having a mature implementation.
One of the big problems with ARM SoCs is that a mature implementation (to me at least) means having good, stable drivers that are well supported and updatable for the rest of the OS stack (i.e. you want to make sure that there is a suitable Xorg driver when the distro moves to a new version of Xorg with a new ABI.
By that measure there is no such thing as a mature ARM SoC implementation, and there will not be until there is an OSS driver for PowerVR. Given it has taken the best part of a decade to get stable accelerated ATI and Nvidia drivers (which are still, BTW, nowhere nearly as accelerated as you might think), unless there is suddenly a big drive for raising millions for funding development of an OSS PowerVR driver, I wouldn't put much stock in seeing such a thing available before the end of this decade.
Freescale's roadmap is based on waiting until the platform is at a point where it won't cause significant problems to the rollout of the chip - less errata to deal with, ideally less chance of a major automotive customer having cars sold where the dashboard stops working. They'll hit Cortex-A9 at a fairly decent revision, with a very tight integration and an optimized core on an optimized process. TI is trying to be ahead of it's competitors which will result, yet again, in a chip which is going to take 2 years to actually get anywhere in the market.
And they'll still be a year before everyone else. Companies like Nvidia are talking about shipping A15 based SoCs in 2012.
This is not the Intel/AMD Windows market where every 3 months you need to release something faster, and faster, and faster. To give a very recent and very relevant example, Intel just screwed up their southbridge for the second generation Core i7. It's cost them over half a billion dollars to try and be the latest and greatest and rush chips out. We have had that with chips in the past, trying to be there too fast, and it costs money, and causes strife for customers.
Sure, but that happens once a decade or so, and the figures you mention are for the volume shipments are measured in hundreds of thousands. Then again, I do recognize the point that a smaller company can afford such a failure far less than Intel.
I'll say it again, if you want 2GHz, dual core, 16GB dual-channel DDR3 RAM, 800MHz memory controllers, go buy a PC. You're in the wrong market. Neither ARM nor Freescale or even TI are designing chips for power users;
We're not talking about power use here. We're talking about "good enough".
the expected panel resolution is 1024x600. It's very common.
Oh come on. 1024x600 isn't really adequate. It only ever took off because of the initial rush to the market was driven by products that were as cheap as possible. It was a novelty to have a tiny laptop, even if it was no good. 1024x600 is barely adequate for something that is just too painful on an 800x480 phone. And since 10in screens running 1366x768 are easily available, it's hardly justifiable from the usability point of view. In the x86 world there are no doubt thousands of those who don't know better and will buy such things because they're cheap. But given the price tag on ARM based smartbooks is no lower and the only people likely to buy them are the select elite, there is a lot to be said for building a product that the only likely audience would want. And in this case they will most certainly want something better than 1024x600, even if it costs them an extra $20.
Go look at the Blackberry PlayBook, AI TouchBook, etc. - this is the desired form factor, this is what the vendors want, it is what the target users are looking for (and the targets are kids, people who don't do well with computers and are a little bit frightened by a wailing, 17" hulk on their desk just to do word processing and go to Facebook) and the market they are trying to capture is not People Who Compile Software A Lot And Need Tons Of Memory and Enough Processing Power to Make You Dizzy.
I can't help but think that the market they are trying to capture isn't going to be very responsive. How many non-geeks have bought ARM based netbooks? They are going to be the select elite from among those who might run Linux on their x86 netbooks. I don't think it's sane to be speccing up a low-end system targeting the unclued-up users using unfamiliar software, and trying to compete with x86 on price. For the life of me I cannot see that being a successful business strategy.
Toshiba tried to side-step the issue by shipping the AC100 with Android, and that was a massive fiasco resulting from seemingly nobody checking the usability of Android on a non-touchscreen device. Great as a Linux laptop (if only accelerated Xorg drivers worked), but using Android without a touchscreen is at best an alien and difficult experience.
Having said all that - the one thing that applies to both the consumer and geek markets is usability. Toshiba failed it due to shipping Android on the AC100. My Efika MX's usability got salvaged from the jaws of defeat by some software hacking to re-map keyboard keys to replace the completely unusable mouse buttons integrated into the glide-pad.
I call them the Numbers Brigade because the actual usefulness of the device as a holistic computing solution is not relevant to them, it's the bullet points on the processor datasheet compared to another one, and the prospect of a new one coming out soon that will outclass it based entirely on the theoretical math of seeing which number is bigger without taking into account the way the components interact. They are the kind of people who live in a constant state of early adoption and infinite buyer's remorse. While you might think they make up a significant percentage of PC sales through their rampant purchasing of new technology at high prices and low turnaround times, they simply don't.
Except we aren't talking about PC sales here. If anybody is likely to have buyer's remorse when acquiring ARM based netbooks it's exactly the average users you describe. They are the ones that are going to be least able to deal with Android without a touchscreen, lack of working flash (no youtube), lack of video acceleration, and lack of reliably and unobtrusively functioning mouse buttons. The geeks will likely get together and hack up a solution that makes the situation bearable. The rest will either send the product back as unfit for purpose, ebay it, or shelve it and never look at it again while spreading bad word about the product.
Maybe when the Cortex-A15 is out and we have ARM servers floating around,
ARM servers are already floating around. ZT systems have released such a thing. It's not cheap, but if you are up against the wall on data centre power consumption and cooling it is well within the realm of plausible when it comes to value for money. It has dual core A9s in it (8 of them):
http://www.ztsystems.com/Default.aspx?tabid=1483
the dream of a Power User ARM Smartbook with a huge screen, a ton of RAM and processing power enough to spook a horse will be fulfilled. Good luck waiting for 2015 for that one, in the meantime I guarantee the first usable Cortex-A15 unit on the market will be dual core, less than 1.5GHz, and have an 11" 720p screen on it.
You may be right about an A15, but a large-screened A9 should be more than plausible today. The AC100 has a HDMI output and can (supposedly - haven't tested it myself yet) handle outputting a 1080 signal. I tried fitting a 720p panel into it, but Toshiba did some firmware "sabotaging" that makes higher res panels not work, but I don't have any reason to think this is for reasons for any hardware limitations, it's almost certainly a firmware issue. And if it can output a 1080p HDMI signal, I don't see why there would be a reason why you couldn't output that 1080p via LVDS to a TFT panel.
Gordan
On Wed, Feb 2, 2011 at 12:05 PM, Gordan Bobic gordan@bobich.net wrote:
The way forward here would be a SATA port. Anything else doesn't cut it in terms of performance, and even on something as low on CPU as an 800MHz A8 still suffers significant slow-down when working off SD cards. This has a massive effect on perceived performance, especially with only 512MB of RAM for caching to cover up the deficiency.
Annoyingly, I've not yet seen a production ARM based netbook with a SATA port.
that's why i designed a standard based around having an SATA port, even if it means converting to SATA. so, the S5PV210 has CF/ATA (aka IDE, UDMA Mode 5) and Genesys Logic (not to be confused with genesi-usa!) have given me a very good quote on an IDE-to-SATA converter.
I agree wholeheartedly (see above..) with the video playback thing. A laptop *only* good as a compiler box won't sell.
Perhaps you can tell us, then, when the Efika MX will have accelerated drivers available? The video poing keeps coming up, but Xorg on my Efika MX is running off raw fbdev on mine and none of the standard acceleration APIs work (e.g. XV).
*grins*. gotta love texas instruments. xorg-video-omapfb _and_ with xv support he he. sorry, matt, couldn't help that small dig, there :)
One of the big problems with ARM SoCs is that a mature implementation (to me at least) means having good, stable drivers that are well supported and updatable for the rest of the OS stack (i.e. you want to make sure that there is a suitable Xorg driver when the distro moves to a new version of Xorg with a new ABI.
this is chicken-and-egg, and it _requires_ someone to make the first jump, tolerate things for a while and to badger the bloody SoC vendors to stop with the stupid rules.
I'll say it again, if you want 2GHz, dual core, 16GB dual-channel DDR3 RAM, 800MHz memory controllers, go buy a PC. You're in the wrong market. Neither ARM nor Freescale or even TI are designing chips for power users;
We're not talking about power use here. We're talking about "good enough".
the expected panel resolution is 1024x600. It's very common.
Oh come on. 1024x600 isn't really adequate. It only ever took off because of the initial rush to the market was driven by products that were as cheap as possible.
the chinese market is ahead of the times (it's far bigger). the chinese home market has REJECTED the 1024x600 screen size. and the primary reason for that is that 800x480 phone sizes are about as tolerable as 1024x600 screen sizes, yet the 800x480 fits in a pocket and is not needed *all the time*. for the chinese home market, 12in is now considered to a minimum requirement. it's only the rest of the world which haven't yet caught on.
run Linux on their x86 netbooks. I don't think it's sane to be speccing up a low-end system targeting the unclued-up users using unfamiliar software, and trying to compete with x86 on price. For the life of me I cannot see that being a successful business strategy.
thaat's why i'm working on a strategy which gets well below the x86 price-point, but where the end-product range is flexible... don't want to go into too many details.
functioning mouse buttons. The geeks will likely get together and hack up a solution that makes the situation bearable. The rest will either send the product back as unfit for purpose, ebay it, or shelve it and never look at it again while spreading bad word about the product.
PRECISELY, and this is why it is so so vital to get _something_ - a product range that satisfied BOTH markets, so that geeks will begin to do the work that the vendors themselves cannot even remotely contemplate doing, or even understand. geeks who are tolerant enough of the foibles and who know that, at the end of the day, _after_ their efforts, they'll have something that they're truly satisfied with.
Maybe when the Cortex-A15 is out and we have ARM servers floating around,
ARM servers are already floating around. ZT systems have released such a thing. It's not cheap, but if you are up against the wall on data centre power consumption and cooling it is well within the realm of plausible when it comes to value for money. It has dual core A9s in it (8 of them):
ahh, ha haaaaa, you're a starr, gordon. i might be able to work with this.
You may be right about an A15, but a large-screened A9 should be more than plausible today. The AC100 has a HDMI output and can (supposedly - haven't tested it myself yet) handle outputting a 1080 signal. I tried fitting a 720p panel into it, but Toshiba did some firmware "sabotaging" that makes higher res panels not work, but I don't have any reason to think this is for reasons for any hardware limitations, it's almost certainly a firmware issue.
ARM CPUs don't have the concept of a BIOS, so the screen timings are hard-coded into the kernel driver. you *can't* just whop a new screen in and expect it to work, you *have* to recompile the kernel, hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate, pixel density *everything*.
fortunately toshiba have complied with GPL requests for the kernel source code, so you can grab it and recompile. also fortunately, the boot loader system is now well-understood, if a little bloody awkward. so you can test new kernels booting off of SD-card by holding a key, and you can blow away android entirely by writing to the internal /dev/mmcblk0p6 partition. no you _can't_ write to anything _but_ the /dev/mmcblk0p6. get the external boot working first otherwise you'll be left without a means to recover after blowing away mmcblk0p6 ;)
l.
Luke Kenneth Casson Leighton wrote:
On Wed, Feb 2, 2011 at 12:05 PM, Gordan Bobic gordan@bobich.net wrote:
The way forward here would be a SATA port. Anything else doesn't cut it in terms of performance, and even on something as low on CPU as an 800MHz A8 still suffers significant slow-down when working off SD cards. This has a massive effect on perceived performance, especially with only 512MB of RAM for caching to cover up the deficiency.
Annoyingly, I've not yet seen a production ARM based netbook with a SATA port.
that's why i designed a standard based around having an SATA port, even if it means converting to SATA. so, the S5PV210 has CF/ATA (aka IDE, UDMA Mode 5) and Genesys Logic (not to be confused with genesi-usa!) have given me a very good quote on an IDE-to-SATA converter.
I agree wholeheartedly (see above..) with the video playback thing. A laptop *only* good as a compiler box won't sell.
Perhaps you can tell us, then, when the Efika MX will have accelerated drivers available? The video poing keeps coming up, but Xorg on my Efika MX is running off raw fbdev on mine and none of the standard acceleration APIs work (e.g. XV).
*grins*. gotta love texas instruments. xorg-video-omapfb _and_ with xv support he he. sorry, matt, couldn't help that small dig, there :)
One of the big problems with ARM SoCs is that a mature implementation (to me at least) means having good, stable drivers that are well supported and updatable for the rest of the OS stack (i.e. you want to make sure that there is a suitable Xorg driver when the distro moves to a new version of Xorg with a new ABI.
this is chicken-and-egg, and it _requires_ someone to make the first jump, tolerate things for a while and to badger the bloody SoC vendors to stop with the stupid rules.
I'll say it again, if you want 2GHz, dual core, 16GB dual-channel DDR3 RAM, 800MHz memory controllers, go buy a PC. You're in the wrong market. Neither ARM nor Freescale or even TI are designing chips for power users;
We're not talking about power use here. We're talking about "good enough".
the expected panel resolution is 1024x600. It's very common.
Oh come on. 1024x600 isn't really adequate. It only ever took off because of the initial rush to the market was driven by products that were as cheap as possible.
the chinese market is ahead of the times (it's far bigger). the chinese home market has REJECTED the 1024x600 screen size. and the primary reason for that is that 800x480 phone sizes are about as tolerable as 1024x600 screen sizes, yet the 800x480 fits in a pocket and is not needed *all the time*. for the chinese home market, 12in is now considered to a minimum requirement. it's only the rest of the world which haven't yet caught on.
run Linux on their x86 netbooks. I don't think it's sane to be speccing up a low-end system targeting the unclued-up users using unfamiliar software, and trying to compete with x86 on price. For the life of me I cannot see that being a successful business strategy.
thaat's why i'm working on a strategy which gets well below the x86 price-point, but where the end-product range is flexible... don't want to go into too many details.
functioning mouse buttons. The geeks will likely get together and hack up a solution that makes the situation bearable. The rest will either send the product back as unfit for purpose, ebay it, or shelve it and never look at it again while spreading bad word about the product.
PRECISELY, and this is why it is so so vital to get _something_ - a product range that satisfied BOTH markets, so that geeks will begin to do the work that the vendors themselves cannot even remotely contemplate doing, or even understand. geeks who are tolerant enough of the foibles and who know that, at the end of the day, _after_ their efforts, they'll have something that they're truly satisfied with.
Maybe when the Cortex-A15 is out and we have ARM servers floating around,
ARM servers are already floating around. ZT systems have released such a thing. It's not cheap, but if you are up against the wall on data centre power consumption and cooling it is well within the realm of plausible when it comes to value for money. It has dual core A9s in it (8 of them):
ahh, ha haaaaa, you're a starr, gordon. i might be able to work with this.
You may be right about an A15, but a large-screened A9 should be more than plausible today. The AC100 has a HDMI output and can (supposedly - haven't tested it myself yet) handle outputting a 1080 signal. I tried fitting a 720p panel into it, but Toshiba did some firmware "sabotaging" that makes higher res panels not work, but I don't have any reason to think this is for reasons for any hardware limitations, it's almost certainly a firmware issue.
ARM CPUs don't have the concept of a BIOS, so the screen timings are hard-coded into the kernel driver. you *can't* just whop a new screen in and expect it to work, you *have* to recompile the kernel, hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate, pixel density *everything*.
So, I should blame the kernel for not reading the EDID on the panel? Can you point me at the relevant bit of the kernel code? If you're right, then a 720p panel may not be implausible. But my understanding is that the screen gets setup by the boot loader, and the Tegra FB driver just works based on that, it doesn't configure anything itself. If that is the case, then the boot loader itself would likely need to be reconfigured, or the TegraFB driver taught to configure the display geometry. The latter may be difficult given that nvidia aren't exactly renowned for publishing their specs.
fortunately toshiba have complied with GPL requests for the kernel source code, so you can grab it and recompile. also fortunately, the boot loader system is now well-understood, if a little bloody awkward.
I just use the recovery kernel partition image to boot non-andorid.
so you can test new kernels booting off of SD-card by holding a key, and you can blow away android entirely by writing to the internal /dev/mmcblk0p6 partition. no you _can't_ write to anything _but_ the /dev/mmcblk0p6. get the external boot working first otherwise you'll be left without a means to recover after blowing away mmcblk0p6 ;)
Yes, I know how it works. :)
Gordan
On Wed, Feb 2, 2011 at 1:41 PM, Gordan Bobic gordan@bobich.net wrote:
ARM CPUs don't have the concept of a BIOS, so the screen timings are hard-coded into the kernel driver. you *can't* just whop a new screen in and expect it to work, you *have* to recompile the kernel, hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate, pixel density *everything*.
So, I should blame the kernel for not reading the EDID on the panel?
the EDID data is generally completely ignored by the linux kernel for LCD panels, in embedded systems. it's only typically when that panel ends up in an LCD monitor and shoved over DVI, HDMI or VGA by virtue of the IC controller chip having the necessary I2C logic that EDID data ends up being read. but in embedded systems, changing the LCD panel _just_ doesn't happen, and the linux kernel source code for such devices typically reflects this by having the panel's settings hard-coded in.
so... yes :)
Can you point me at the relevant bit of the kernel code?
aw gawd come on, gordan :)
If you're right, then a 720p panel may not be implausible. But my understanding is that the screen gets setup by the boot loader, and the Tegra FB driver just works based on that, it doesn't configure anything itself.
hmmm, that sounds about right. and if you don't mind a bit of "bzzzt" and not being able to see anything during the boot process, you should be able to overwrite whatever crud settings the bootloader decided to set, once you've started the linux kernel.
the tegra fb kernel driver _should_ be setting them anyway.
If that is the case, then the boot loader itself would likely need to be reconfigured, or the TegraFB driver taught to configure the display geometry.
yyep.
The latter may be difficult given that nvidia aren't exactly renowned for publishing their specs.
it's nothing to do with nvidia, and everything to do with the timings of the LCD. ahh, i see what you mean, you'd need to know where the registers are for blopping in the hsync, vsync etc. etc. timings.
yep, you're right. *sigh* that'll need investigating.
ok - start here. https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi
/dev/mmcblk0p6. get the external boot working first otherwise you'll be left without a means to recover after blowing away mmcblk0p6 ;)
Yes, I know how it works. :)
ah goood :)
On Wed, Feb 2, 2011 at 9:30 AM, Luke Kenneth Casson Leighton luke.leighton@gmail.com wrote:
On Wed, Feb 2, 2011 at 1:41 PM, Gordan Bobic gordan@bobich.net wrote:
ARM CPUs don't have the concept of a BIOS, so the screen timings are hard-coded into the kernel driver. you *can't* just whop a new screen in and expect it to work, you *have* to recompile the kernel, hard-coding the hsync, vsync, offsets, hclock, vclock, pixel rate, pixel density *everything*.
So, I should blame the kernel for not reading the EDID on the panel?
the EDID data is generally completely ignored by the linux kernel for LCD panels, in embedded systems. it's only typically when that panel ends up in an LCD monitor and shoved over DVI, HDMI or VGA by virtue of the IC controller chip having the necessary I2C logic that EDID data ends up being read. but in embedded systems, changing the LCD panel _just_ doesn't happen, and the linux kernel source code for such devices typically reflects this by having the panel's settings hard-coded in.
so... yes :)
No, Luke. This is a complete misconception.
Most panels have EDID data that is perfectly valid.
Not reading the EDID is laziness.
99% of embedded panels expose the DDC lines to the host - you just wire up an i2c controller. It is not common for the panel controller (either LVDS or TMDS or whatever) to arbitrate access to the i2c bus used for DDC except when HDCP is required (and accessing DDC data is a violation of the security framework).
Embedded systems that have anything approaching a VGA sized panel should be reading the EDID, but most devices *never* accept more than one panel. In this case reading the EDID is redundant. Some developers consider it a waste of time to plug in the one mode supported from the EDID when they can copy the data from the spec sheet.
In the event a different panel is used, the EDID is the sole, only way of differentiating between panels without additional hardware support or having a kernel for each panel.
If you're right, then a 720p panel may not be implausible. But my understanding is that the screen gets setup by the boot loader, and the Tegra FB driver just works based on that, it doesn't configure anything itself.
hmmm, that sounds about right. and if you don't mind a bit of "bzzzt" and not being able to see anything during the boot process, you should be able to overwrite whatever crud settings the bootloader decided to set, once you've started the linux kernel.
The screen on the Smartbook is set up by the MTL017 driver. It's been coded in Taiwan so it hardcodes the MTL017 configuration as an unhealthy block of 256 byte values and just hammers the chip with it. Genesi accepts that it is godawful way to do it and we are not happy with the code we were provided with. But it does read the EDID so it knows what panel data to send depending on the panel attached via the EDID. We're rewriting it to use the EDID properly here.
Luke Kenneth Casson Leighton wrote:
Can you point me at the relevant bit of the kernel code?
aw gawd come on, gordan :)
The point I was getting at is that the Tegra FB driver doesn't do this at all. It's very minimalistic.
If you're right, then a 720p panel may not be implausible. But my understanding is that the screen gets setup by the boot loader, and the Tegra FB driver just works based on that, it doesn't configure anything itself.
hmmm, that sounds about right. and if you don't mind a bit of "bzzzt" and not being able to see anything during the boot process, you should be able to overwrite whatever crud settings the bootloader decided to set, once you've started the linux kernel.
the tegra fb kernel driver _should_ be setting them anyway.
I'll take another look, but I'm 99% certain it doesn't. And my post to the nvidia tegra developer forum regarding this went predictably unanswered.
The latter may be difficult given that nvidia aren't exactly renowned for publishing their specs.
it's nothing to do with nvidia, and everything to do with the timings of the LCD. ahh, i see what you mean, you'd need to know where the registers are for blopping in the hsync, vsync etc. etc. timings.
That's what I'm talking about.
yep, you're right. *sigh* that'll need investigating.
ok - start here. https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi
You're missing the point - there is no code that does the screen geometry setup already available that I'm aware of. The really shocking part is that the binary closed-source Xorg driver doesn't handle EDID either. Or rather - it _does_ (it's reported on Xorg.log) - but it is always the same regardless of the panel used. So either it is hard-coded in the driver or it is somewhere sufficiently low-level to intercept and override what comes back from the panel.
Gordan
On Wed, Feb 2, 2011 at 3:49 PM, Gordan Bobic gordan@bobich.net wrote:
Luke Kenneth Casson Leighton wrote:
Can you point me at the relevant bit of the kernel code?
aw gawd come on, gordan :)
The point I was getting at is that the Tegra FB driver doesn't do this at all. It's very minimalistic.
ouch.
ok - start here. https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi
You're missing the point - there is no code that does the screen geometry setup already available that I'm aware of.
noo, i get it - just didn't say it explicitly, apologies.
l.
2011/2/2 Misha Shnurapet shnurapet@fedoraproject.org:
01.02.2011, 05:51, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
01.02.2011, 21:33, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
but, yeah, the aim is to fulfil the largest number of peoples' needs first (weight of numbers) and then branch out from there.
Hi, Luke.
Thank you for the proposal and none the less interesting discussion. It's people like you who actually "get us there" at end, and it's good to know that possible ways are being searched for.
appreciated the encouragement misha. the plan involves bootstrapping the way up from low-level beginnings all the way up to mass-volume products. the pieces are falling into place, and it's through other people helping to find things (like gordon finding that ztsystems server, which leads to phytec) that it will get there quicker.
http://www.phytec.com/news/ZT-Systems-R1801e-Server.html
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
yep - all the designs i've worked on, and all the CPUs found (so far) were selected precisely because of the HDMI output capability. i'd kinda ruled out the spea1310 because you need an extra IC converting LCD to DVI/HDMI or even *shudder* a PCI-e graphics IC (volari Z11 god help us is about the only free-software-compatible option)
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The gorgeously-looking Efika MX would fit me almost perfectly if not the soon-deprecating A8 CPU and the plans for a dual-core solution with faster RAM.
this has been answered very well by others.
l.
Luke Kenneth Casson Leighton wrote:
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
yep - all the designs i've worked on, and all the CPUs found (so far) were selected precisely because of the HDMI output capability. i'd kinda ruled out the spea1310 because you need an extra IC converting LCD to DVI/HDMI or even *shudder* a PCI-e graphics IC (volari Z11 god help us is about the only free-software-compatible option)
I was just thinking about that, actually. If you're making a custom mobo, then as long as you can find an ARM SoC tht has PCI-e, you could just apply an MXM module and plug in an ATI or Nvidia GPU for which we already have passably working OSS drivers.
Of course, this defeats the purpose of the exercise - who in their right mind would use a 2W CPU with a 30W+ GPU in a laptop?
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark, and manufacturers are free to do their own testing. Most fail any sane real-world measurements of the specification.
Just about every SD card I have seen apart from high end Lexar and SanDisk manage a whopping 1-3 4KB write IOPS. Team Class 10 32GB SD card is among those. So the class rating is pretty much completely meaningless for anything except (at most) digital camera use where you are sequentially writing large files to a FAT32 file system.
I'm glad we agree on anything other than SATA being unworkable. :)
Gordan
On Wed, Feb 2, 2011 at 10:02 AM, Gordan Bobic gordan@bobich.net wrote:
Luke Kenneth Casson Leighton wrote:
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
yep - all the designs i've worked on, and all the CPUs found (so far) were selected precisely because of the HDMI output capability. i'd kinda ruled out the spea1310 because you need an extra IC converting LCD to DVI/HDMI or even *shudder* a PCI-e graphics IC (volari Z11 god help us is about the only free-software-compatible option)
I was just thinking about that, actually. If you're making a custom mobo, then as long as you can find an ARM SoC tht has PCI-e, you could just apply an MXM module and plug in an ATI or Nvidia GPU for which we already have passably working OSS drivers.
Of course, this defeats the purpose of the exercise - who in their right mind would use a 2W CPU with a 30W+ GPU in a laptop?
Not to mention cost. Unless it is in significant (>100,000 unit) quantities, MXM modules are $100 a pop. Even then, it is not a great discount.
Who in their right mind would pair an $18 SoC with a $100 GPU? It is design insanity to quadruple the BOM like this.
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark
(there is, but you need to be a paid up member of the SD Association to get it)
I'm glad we agree on anything other than SATA being unworkable. :)
I will also point out that a SATA NAND controller that is capable of more than 20MB/s is going to cost you about $2.50 per gigabyte, minimum $35. 2.5" SATA SSDs disks are also rather large for the purpose. Sandisk make some nice MicroSATA SSDs as do, now, Toshiba if you have a December 2010 MacBook Air, but they are either not as fast as you want (20-30MB/s), or more expensive than the rest of the board put together. There is a very good reason Apple's hardware costs so much money and it is absolutely not price gouging.
(side note: We designed a developer system for IBM once; a quad core G5 workstation, an open source, open design alternative to the Mac cheesegrater. When it turned out the board alone would cost more than buying a Mac G5 we handed them the schematics and the spec and abandoned the project. Nobody wants a $1500 motherboard with a $1500 CPU set, and being told to buy your own hard disks, when you can go to Apple and buy it prebuilt with cooling and graphics card and an operating system for the same price.)
If you want cheap, plentiful and fast NAND on the board, you would be better off using the internal flash controllers and soldering the chips to the board. However you are limited by size and of course the performance is not as you would expect (NAND disk does not necessarily equate to 215MB/s Intel X series performance. Intel have a very specific configuration to get that speed. Embedded NAND controllers won't do it. Embedded SATA controllers won't even get the full performance of the Intel devices).
This is exactly where you will get if you're trying to massage the Tegra2, MX53, OMAP4 into a high end laptop; it will not meet your expectations. They are not designed for those environments. Tegra and OMAP4 are phone/tablet chips almost entirely focused on Android. MX53 is for in-flight entertainment, Ford Sync, handheld media tablets, that kind of thing. Remember when you think about speeds on devices, they are always listed as maximums. Yes, SATA-II is 3Gbit/s (actually about 2.4Gbit after you get past the 10-8 encoding) but does a device need to run at that? Not at all. USB 480Mbit/s? Nope.
You can't design a system, keep it cheap and make it a volume seller by just picking the chips with the biggest numbers.
2011/2/2 Matt Sealey matt@genesi-usa.com
On Wed, Feb 2, 2011 at 10:02 AM, Gordan Bobic gordan@bobich.net wrote: This is exactly where you will get if you're trying to massage the Tegra2, MX53, OMAP4 into a high end laptop; it will not meet your expectations. They are not designed for those environments. Tegra and OMAP4 are phone/tablet chips almost entirely focused on Android. MX53 is for in-flight entertainment, Ford Sync, handheld media tablets, that kind of thing. Remember when you think about speeds on devices, they are always listed as maximums. Yes, SATA-II is 3Gbit/s (actually about 2.4Gbit after you get past the 10-8 encoding) but does a device need to run at that? Not at all. USB 480Mbit/s? Nope.
You can't design a system, keep it cheap and make it a volume seller by just picking the chips with the biggest numbers.
The trick is, pick one component and select all other components as cheap as possible, but still not bottlenecking the whole system. I got rather small experience in System design, but if you intend to do so, get some money-monkey keeping an eye on the BOM and timeline.
Just my 2 cents.
Regards
Bernhard Schuster
Matt Sealey wrote:
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
yep - all the designs i've worked on, and all the CPUs found (so far) were selected precisely because of the HDMI output capability. i'd kinda ruled out the spea1310 because you need an extra IC converting LCD to DVI/HDMI or even *shudder* a PCI-e graphics IC (volari Z11 god help us is about the only free-software-compatible option)
I was just thinking about that, actually. If you're making a custom mobo, then as long as you can find an ARM SoC tht has PCI-e, you could just apply an MXM module and plug in an ATI or Nvidia GPU for which we already have passably working OSS drivers.
Of course, this defeats the purpose of the exercise - who in their right mind would use a 2W CPU with a 30W+ GPU in a laptop?
Not to mention cost. Unless it is in significant (>100,000 unit) quantities, MXM modules are $100 a pop. Even then, it is not a great discount.
Who in their right mind would pair an $18 SoC with a $100 GPU? It is design insanity to quadruple the BOM like this.
Indeed, it's not sensible even if does gain the "OSS drivers" feature.
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark
(there is, but you need to be a paid up member of the SD Association to get it)
Whatever it is, it appears to have been designed specifically to be completely meaningless.
I'm glad we agree on anything other than SATA being unworkable. :)
I will also point out that a SATA NAND controller that is capable of more than 20MB/s is going to cost you about $2.50 per gigabyte, minimum $35. 2.5" SATA SSDs disks are also rather large for the purpose. Sandisk make some nice MicroSATA SSDs as do, now, Toshiba if you have a December 2010 MacBook Air, but they are either not as fast as you want (20-30MB/s), or more expensive than the rest of the board put together. There is a very good reason Apple's hardware costs so much money and it is absolutely not price gouging.
It's not about bandwidth, it's about latencies. Embedded NAND just doesn't seem to deliver and non-SSD modular flash (e.g. SD/CF) is appalling. A SATA controller would fix the problem because you could plug in a $100 X25-V and be done with it (instead of a $200 SD card 3/4 of the size and 1/10 of the performance). If I can get 1200 IOPS out of the SD card on reads, the interface can handle it - I'll be more than happy with 1200 IOPS on writes that the SD interface can deliver, but the suitably performing media doesn't exist. SATA media handles it just fine, OTOH, and given the most recent X25 series shrink, it looks like a no-brainer when it comes to TCO. I'd rather pay an extra $100 for the base machine + another $100 for a decent SSD than pay $100 less for the machine and pay $200 for the flash media that is 10x worse. The TCO ends up the same but the performance in the SATA case is 100x+ better. Not really a difficult decision. SD and CF media is vastly overpriced and it sounds crazy to use it when there are much better and cheaper alternatives.
If you want cheap, plentiful and fast NAND on the board, you would be better off using the internal flash controllers and soldering the chips to the board. However you are limited by size and of course the performance is not as you would expect (NAND disk does not necessarily equate to 215MB/s Intel X series performance. Intel have a very specific configuration to get that speed. Embedded NAND controllers won't do it. Embedded SATA controllers won't even get the full performance of the Intel devices).
It doesn't need to hit the performance that the Intel X25 can deliver, it just has to enable usage of a device that can saturate it. SD cards just don't cut it - period.
This is exactly where you will get if you're trying to massage the Tegra2, MX53, OMAP4 into a high end laptop; it will not meet your expectations.
My expectations in this regard are: 1200 IOPS on random 4KB reads and writes. SD interface can deliver this read performance easily. _NO_ SD card can deliver this write performance, but a SATA SSD half the price and double the capacity can. Sure, the disk may not reach it's potential limit but so what - you'll still end up with a laptop that is 100x faster for less cost or at least comparable cost.
They are not designed for those environments. Tegra and OMAP4 are phone/tablet chips almost entirely focused on Android. MX53 is for in-flight entertainment, Ford Sync, handheld media tablets, that kind of thing. Remember when you think about speeds on devices, they are always listed as maximums. Yes, SATA-II is 3Gbit/s (actually about 2.4Gbit after you get past the 10-8 encoding) but does a device need to run at that? Not at all. USB 480Mbit/s? Nope.
You can't design a system, keep it cheap and make it a volume seller by just picking the chips with the biggest numbers.
I'm not talking about chip-picking I'm talking about price/performance of components. This wouldn't be an issue of the port on the back of the Efika MX was suitable for a 1.8in SATA SSD. Unfortunately, it's uSD, and that means it is limited by media availability to 1 write IOPS with more expensive media. For anybody intending to use this non-removable expansion slot (e.g. for a different OS), that is a seriously false economy.
Gordan
On Wed, Feb 2, 2011 at 4:02 PM, Gordan Bobic gordan@bobich.net wrote:
Luke Kenneth Casson Leighton wrote:
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
yep - all the designs i've worked on, and all the CPUs found (so far) were selected precisely because of the HDMI output capability. i'd kinda ruled out the spea1310 because you need an extra IC converting LCD to DVI/HDMI or even *shudder* a PCI-e graphics IC (volari Z11 god help us is about the only free-software-compatible option)
I was just thinking about that, actually. If you're making a custom mobo, then as long as you can find an ARM SoC tht has PCI-e, you could just apply an MXM module and plug in an ATI or Nvidia GPU for which we already have passably working OSS drivers.
Of course, this defeats the purpose of the exercise - who in their right mind would use a 2W CPU with a 30W+ GPU in a laptop?
*ROTFL*. yyep. the volari z11 is what ended up in the openrd ultimate, for pretty much these reasons. yes, i've been looking around for an IC that does 3D graphics at lower power. there are a couple from broadcomm but broadcomm are a f*****g nightmare to work with. their attitude can be summarised as "your product will fail, therefore we are not interested".
it's very interesting that it's been the U.S. companies whose attitude has been "your product will fail, therefore we do not wish to be involved". i find this fascinating.
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark, and manufacturers are free to do their own testing. Most fail any sane real-world measurements of the specification.
oops.
I'm glad we agree on anything other than SATA being unworkable. :)
weell, i'm covering all the angles. genesyslogic's ICs are about $1 - $1.50 even in small volumes so it's not as if it'll break the bank by putting one on the motherboard, in the case where the CPU itself doesn't have SATA.
Luke Kenneth Casson Leighton wrote:
I'm glad we agree on anything other than SATA being unworkable. :)
weell, i'm covering all the angles. genesyslogic's ICs are about $1
- $1.50 even in small volumes so it's not as if it'll break the bank
by putting one on the motherboard, in the case where the CPU itself doesn't have SATA.
Even SDIO->SATA would be an improvement, just to get away from the unspeakable uselessness of SD media.
Gordan
On Wed, Feb 2, 2011 at 10:32 AM, Luke Kenneth Casson Leighton luke.leighton@gmail.com wrote:
On Wed, Feb 2, 2011 at 4:02 PM, Gordan Bobic gordan@bobich.net wrote:
Luke Kenneth Casson Leighton wrote:
it's very interesting that it's been the U.S. companies whose attitude has been "your product will fail, therefore we do not wish to be involved". i find this fascinating.
It is far more subtle than that. Note the job title: I do product development for a living. Your product won't fail - I am sure if you find the money to advance development beyond pre-production prototype, and that is a rather significant amount of money, you might sell a few units. Getting industrial design done, EMI testing, FCC/CE/NOM certification, and then ramping it up to a reasonable production economy will double your budget, minimum. Don't forget shipping them from Taiwan, freight, and delays in part ordering, and price fluctuations making your hair fall out.
Designing an ARM Netbook is going to cost you about a million bucks out of pocket for the first 1,000 units. You'd better be willing to sell them for $1000 each to recoup the costs involved if you want it back immediately. Can you guarantee you'll sell 1,000 units on a consumer level? Can you guarantee 10,000? In that case you can offset the cost and give your system an ultimate BOM cost of $100 and sell it for about $250.
Without those guarantees and without up front funding and investment, your product will fail. No company would take on the project if it meant expending significant resources on something that at best case end up as a doorstop. I can point you at several "community efforts" which do mean well but have ended up basically either being chucked in the trash or not being anything close to viable. Remeber the Crunchpad that became the JooJoo? Without the nitty gritty details I can't say what actually went on between Arlington and Fusion Garage but I suspect the reason is Fusion Garage put in significant funding through investors and could not find volume in the market the TechCrunch guys though it would attract, at the price they wanted (which amounts to selling at a loss).
It is not possible to create a loss leader without having something next to it that is not slightly overpriced to compensate. Apple do this with the iPod - the device is sold above manufacturing cost, but well below development cost. They make money on the iTunes store. For every 99 cent tune they sell, they get paid. When they get sold in batches of 12, they get paid 12 times. When 50 million people do it once a week, who cares if they recoup the money on hardware and OS development? Take Android's App Store: the vendors don't get anything, but the App Store drives them to the product. The phones are subsidized by the telecoms companies so that the demand for a fart app can be met with a $99 phone that cost $300 to build. The vendor is happy because they are protected by the subsidization model.and is being paid back in full (+profit) for the cost of the phone, and the telecoms company can do it because it makes a huge profit on the mandatory 2-year subscription ($60 a month for a worth-$10-in-infrastructure data plan pays for your phone in such a way that every phone is written off in 3-4 months and the rest is gravy).
It is all about recouping investment, and no amount of investment in this product being discussed will ever be recouped. You need to find yourselves a wealthy guy who will back your cause. I am surprised Mark Shuttleworth hasn't done something like it already - you'd think the largest most successful consumer-oriented open source distribution in the last 5 years would do well to have development hardware available.
Hello,
Let me introduce myself : Guillaume FORTAINE, Engineer in Computer Science.
I have read with interest the topic started by Mister Leighton entitled " 1ghz ARM Laptop (12in 1280x800 LCD)" and I would greatly appreciate to share my conclusions with you.
First of all, I would want to mention that except the comments of Mister Sealey, coming from a really smart engineer, everything else seems to belong to a "geeky" dream with a lot of misconceptions too numerous to mention.
But to come back to the "1ghz ARM Laptop" topic :
-12in 1280x800
a) You have already 10.1in screens with 1280x720 resolution support [0]
b) You even have 10.1in screens with 1366x768 resolution support [1]
-1Ghz ARM Laptop
As previously mentioned by Forum Blogarm.net, there is Nufront [2] with their NuSmart 2816 SoC (2x2Ghz Cortex A9, Data Brief in English) [3].
And, if your are lazy, like me, you will directly buy a 14'' Nufront Newton [4] (Rock Yang, yuxin.yang@nufront.com, VP Marketing) [5].
Best Regards,
[0] http://support.acer.com/acerpanam/netbook/2011/Acer/Aspire/AspireOneAO522/As... [1] http://www.dell.com/us/p/inspiron-duo/pd [2] http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-January/000823.html [3] http://um00i1.chinaw3.com/Nufront_NuSmartTM_2816_EN.pdf [4] http://www.netbooknews.com/17640/14-nufront-newton-with-the-dual-core-cortex... [5] http://cn.linkedin.com/pub/rock-yang/8/236/93a
Guillaume FORTAINE Tel : +33(0)631092519 Mail : gfortaine@gfortaine.biz ----------------------------------------
Date: Wed, 2 Feb 2011 16:32:55 +0000 From: luke.leighton@gmail.com To: gordan@bobich.net CC: shnurapet@fedoraproject.org; arm@lists.fedoraproject.org; arm-netbook@lists.phcomp.co.uk Subject: Re: [Arm-netbook] [fedora-arm] 1ghz ARM Laptop (12in 1280x800 LCD)
On Wed, Feb 2, 2011 at 4:02 PM, Gordan Bobic wrote:
Luke Kenneth Casson Leighton wrote:
Unfortunately, I'm not a hardware hacker. But, as a consumer, I'd say that a "1gb NAND Flash" is quite a bit below the level. I also wouldn't care much about a 1280x720 screen if the hardware wouldn't be capable of playing the video flawlessly. Or, if there was an HDMI port to connect to TV, which is, in my taste, better suited for watching.
yep - all the designs i've worked on, and all the CPUs found (so far) were selected precisely because of the HDMI output capability. i'd kinda ruled out the spea1310 because you need an extra IC converting LCD to DVI/HDMI or even *shudder* a PCI-e graphics IC (volari Z11 god help us is about the only free-software-compatible option)
I was just thinking about that, actually. If you're making a custom mobo, then as long as you can find an ARM SoC tht has PCI-e, you could just apply an MXM module and plug in an ATI or Nvidia GPU for which we already have passably working OSS drivers.
Of course, this defeats the purpose of the exercise - who in their right mind would use a 2W CPU with a 30W+ GPU in a laptop?
*ROTFL*. yyep. the volari z11 is what ended up in the openrd ultimate, for pretty much these reasons. yes, i've been looking around for an IC that does 3D graphics at lower power. there are a couple from broadcomm but broadcomm are a f*****g nightmare to work with. their attitude can be summarised as "your product will fail, therefore we are not interested".
it's very interesting that it's been the U.S. companies whose attitude has been "your product will fail, therefore we do not wish to be involved". i find this fascinating.
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark, and manufacturers are free to do their own testing. Most fail any sane real-world measurements of the specification.
oops.
I'm glad we agree on anything other than SATA being unworkable. :)
weell, i'm covering all the angles. genesyslogic's ICs are about $1
- $1.50 even in small volumes so it's not as if it'll break the bank
by putting one on the motherboard, in the case where the CPU itself doesn't have SATA.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Guillaume FORTAINE wrote:
But to come back to the "1ghz ARM Laptop" topic :
-12in 1280x800
a) You have already 10.1in screens with 1280x720 resolution support [0]
You either haven't looked very hard or you haven't been paying as much attention as you thought you were. Efika MX can take a 1280x720 screen. I shot down the screen resolution part of the argument in my first retort.
b) You even have 10.1in screens with 1366x768 resolution support [1]
That is the 2nd time you are referencing an Atom netboook with a 25W+ power draw on a thread about ARM netbooks which draw about 5-6W. You really need to stop comparing apples and oranges.
There are also a grand total of three netbooks from 2 manufacturers sporting that 10.1" screen with 1366x768 resolution - The netbook-transforms-to-very-thick-pad Dell you mention, Dell Mini 1012 and the Asus 1005PR. It isn't all that common, and the TFT panel in question is actually quite radically different to most commonly used panels in terms of shape and fittings. It will not fit into other netbook chassies.
-1Ghz ARM Laptop
As previously mentioned by Forum Blogarm.net, there is Nufront [2] with their NuSmart 2816 SoC (2x2Ghz Cortex A9, Data Brief in English) [3]. And, if your are lazy, like me, you will directly buy a 14'' Nufront Newton [4] (Rock Yang, yuxin.yang@nufront.com, VP Marketing) [5].
No mention of screen resolution on the end product, other than the mention of the chip's maximum being 1400x900 over LVDS. That is 16:10 aspect, which is already getting difficult to source, and most of those are unavailable LED backlit, so aren't suitable for low-power laptops. My guess is it won't be available in < 1280x720, which is too low for me on a 14in panel. The laptop is also not mentioned on their website, so I'll believe it when I see it. It may turn out to be an even lazier option than you think - it may involve getting nothing at all.
Gordan
On Wed, 2 Feb 2011, Gordan Bobic wrote:
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark, and manufacturers are free to do their own testing. Most fail any sane real-world measurements of the specification.
Just about every SD card I have seen apart from high end Lexar and SanDisk manage a whopping 1-3 4KB write IOPS. Team Class 10 32GB SD card is among those. So the class rating is pretty much completely meaningless for anything except (at most) digital camera use where you are sequentially writing large files to a FAT32 file system.
I'd suggest you have a look at the work being done by Arnd Bergmann on a new device mapper target to overcome typical SD card misbehavior:
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashDevi...
This is based on a survey of card behavior analysis compiled here:
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCard...
Nicolas
Nicolas Pitre wrote:
On Wed, 2 Feb 2011, Gordan Bobic wrote:
gordon is right about the SD/MMC card thing, but the "level 10" ones can at least guarantee above 10mbytes/sec *read* capability. so _yes_ to the SATA interface.
The 10MB/s is _supposed_ to be for worst-case sequential writes. There is, however, no defined benchmark, and manufacturers are free to do their own testing. Most fail any sane real-world measurements of the specification.
Just about every SD card I have seen apart from high end Lexar and SanDisk manage a whopping 1-3 4KB write IOPS. Team Class 10 32GB SD card is among those. So the class rating is pretty much completely meaningless for anything except (at most) digital camera use where you are sequentially writing large files to a FAT32 file system.
I'd suggest you have a look at the work being done by Arnd Bergmann on a new device mapper target to overcome typical SD card misbehavior:
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashDevi...
That sounds like a very complicated way to work around bad design using a bodge. A much saner solution would be to use something like nilfs2 instead:
Or use something like "Managed Flash" http://managedflash.com/index.htm As far as I can figure it out, it converts all writes to a linear write-ahead log (similar to what databases do, e.g. InnoDB), which is always appended to. Then when there is idle time, you can commit those transactions to where they actually need to be on the disk. Not really ideal, but it's an option if nilfs2 isn't for whatever reason.
This is based on a survey of card behavior analysis compiled here:
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCard...
An interesting list, but basing such assumptions on the way the FAT32 is laid out isn't necessarily sensible. Also remember that most embedded devices (cameras, slates, phones) will blow away the partition table and re-make it when they are told to blank/format the media. Android devices certainly do. I have not yet seen any evidence that shows conclusively that this makes a performance difference in the long-term.
Gordan
Quoting Luke Kenneth Casson Leighton luke.leighton@gmail.com:
2011/2/2 Misha Shnurapet shnurapet@fedoraproject.org:
01.02.2011, 05:51, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
01.02.2011, 21:33, "Luke Kenneth Casson Leighton" luke.leighton@gmail.com:
but, yeah, the aim is to fulfil the largest number of peoples' needs first (weight of numbers) and then branch out from there.
Hi, Luke.
Thank you for the proposal and none the less interesting discussion. It's people like you who actually "get us there" at end, and it's good to know that possible ways are being searched for.
appreciated the encouragement misha. the plan involves bootstrapping the way up from low-level beginnings all the way up to mass-volume products. the pieces are falling into place, and it's through other people helping to find things (like gordon finding that ztsystems server, which leads to phytec) that it will get there quicker.
IIRC zt had announced like 2 years ago it was creating a server based on the Marvell chipset, They had it listed on their website, but no price attached to it.. it was more like vaporware.
There is another startup smooth-stone which seems to have industry backing. http://www.eetimes.com/electronics-news/4206171/ARM--ATIC--TI-invest--48M-in...
couple it with the A15 quad's and you pretty much have a decent solution.
On Thu, 2011-02-03 at 10:14 -0500, omalleys@msu.edu wrote:
couple it with the A15 quad's
I think A15 Quads are quite a ways off -- I've heard it said a numbher of times that when ARM announces something, they're talking about designs (which their partners then build), unlike AMD or Intel who make announcements much closer to the time the silicon will ship. An ARM design announcement is more like an AMD/Intel roadmap announcement in terms of time-to-availability.
-Chris
Quoting Chris Tyler chris@tylers.info:
On Thu, 2011-02-03 at 10:14 -0500, omalleys@msu.edu wrote:
couple it with the A15 quad's
I think A15 Quads are quite a ways off -- I've heard it said a numbher of times that when ARM announces something, they're talking about designs (which their partners then build), unlike AMD or Intel who make announcements much closer to the time the silicon will ship. An ARM design announcement is more like an AMD/Intel roadmap announcement in terms of time-to-availability.
Im not totally disagreeing, but I don't think there is a whole lot of difference between the A15's and the A9's though, after you add the A9 bugfixes. They have 4 processors instead of two, shrink the die, and make the chip so you can up the voltage on it (ie 1.5Mhz for low power cell phones, 2.5Mhz for workstations/servers) and add the ability to use both ddr3 lowE and regular sdram.(ddr3 ecc?)
They were talking about starting to ship about a year or so behind the A9's which are pretty much on time.
-
Bernhard Schuster -
Bill Buck -
Chris Tyler -
Gordan Bobic -
Guillaume FORTAINE -
lkcl . -
Matt Sealey -
Misha Shnurapet -
Nicolas Pitre -
omalleys＠msu.edu