http://en.wikipedia.org/wiki/Jediism#Reaction - wonderful. a jedi knight gets thrown out of a job centre for not removing his hoodie. and a new law in 2010 *excludes* members of the Church of Jediism in the UK from protection against racial discrimination and hatred. wonderful.
i read somewhere that the number of people in the UK who declared themselves as Jedi Knights exceeds the number of people who declared themselves to be Sikhs. however, for some reason, Jediism - http://churchofjediism.org/ - isn't recognised as a religion in the UK.
How soon do you estimate that your company will be selling a computer based on the Allwinner A10?
lots of questions, vairon!:) let me do the best i can. an accurate answer is: we simply can't say. here's a more detailed answer.
based on the simplicity of the concept, which is more or less a cut/paste job for the hardware engineers in China to take the existing tried-and-tested Reference Design direct from AllWinner, if all went well and the hardware engineers were paid to work full-time on this (which they're not!) we could have first early beta boards in as little as 10 working days. then, on top of that, creating an appropriate motherboard is an even more trivial task, because it's only a 2-layer board. the complex part is in creating a case, where the lead times are at least 8 weeks for absolutely everyone in the industry, in China. the complexity and cost here is why we are avoiding, entirely, creating casework for the early prototypes, and are going for something that is more akin to beagleboards, origens, pandaboards and IMX53QSBs. the other option is to find pre-existing casework (for each type of device, be it nettop, laptop or tablet) and to adapt the motherboard to suit. there are thousands of such pre-existing designs available from the Industrial Flea Markets inside China, so it's worthwhile doing that.
so you can see: we'd like to get people involved and give them access to GPL-compliant hardware that, thanks to the modular EOMA-PCMCIA-based approach, will allow them to follow and upgrade from beta-level involvement to mass-volume products (instead of having to first buy a beagleboard for example, then throw it away and buy a mass-volume product with the exact same CPU that's probably GPL-violating and reverse-engineer it). primarily at this critical phase what we need is more Software (Libre) Developers.
Besides more RAM, SATA II interface and higher CPU speed is there anything else that you think will make it more less superior than the Raspberry Pi?
well that's hard to say, because the CPU on the raspberrypi is under strict NDA, and so are we, strictly speaking, with Allwinner. we _have_ however already released the GPL Linux Kernel Source code, so in some ways you're better off asking the raspberrypi team to answer this question.
based on the "publicly available" information about the raspberrypi, i can however make a comparison:
* the allwinner is a Cortex A8 up to 1.5ghz, and the rbpi's CPU is a much older 700mhz ARM11. immediately, therefore, you can say that the rbpi is never going to go above 512mb RAM, and it's also guaranteed to be at least 3x slower than the allwinner.
* the allwinner can take up to 1gb of 800mhz DDR3 RAM. the rbpi CPU i would be very surprised if it could take more than 400mhz DDR2 RAM: as it's reported as capable of HDMI video playback, that *might* be as high as 667mhz DDR2 RAM. the difference that the speed of the RAM makes, especially in these ARM CPUs which have relatively small 1st level caches, is absolutely staggering.
* the GPU from the rbpi CPU is apparently entirely new, proprietary and it looks like it's developed in-house at broadcom. no details available about it, other than "apparently it's fast". no source code, no libraries, no documentation - nothing. the GPU in the allwinner is the standard MALI 400. it's still proprietary, but it's a known quantity.
* the allwinner CPU actually has 4 SD 3.0 ultra-high-speed interfaces, 2 RGB/TTL interfaces (one of which, the pins can be swapped over to an IDE - PATA - interface), USB2-Host as well as USB-OTG, and much more. the kicker for me is the 8-way concurrent DMA-enabled NAND Flash Interface, that can do 8 16 or 32-bit addressing. the speed of read-writes through this would be absolutely phenomenal, and of serious concern in using the full capability would be exceeding the power budgets we've allocated for the EOMA-PCMCIA-compliant interface (5 watts maxim
bonch, i know you may believe that's ok, but it doesn't work that way. apple have violated so many peoples' trust and taken such complete utter control over the hardware and software that you *believe* you own that it's kinda scary to even hear you say "just get an ipad". apple even bought a company - outright - to make their own CPU so that they could do christ knows what - put in DRM or hardware-level monitoring and keystroke logging into the chip? everything about the ipad says to me to run like hell. oh, and i have a friend who works for foxconn - they know the prices of the ipad. it's only $150 FOB out of the factory in china: all the rest is profit for apple. you might want to think about that.
bmsleight - i'm maintaining the list by hand at the moment, if it gets big enough i'll start writing databases / use kickstarter / other but i'll endeavour to contact you via your homepage ok? if you're keeping an eye on this post, email me. thanks. l.
yes it's the standard MALI 400, so the situation is the same as for all other MALI GPU SoCs, which is worth repeating here because it's often misunderstood.
* yes there's a GPL "shim" driver available, which allows the userspace/usr/lib/libgl.so.2 library to communicate with the GPU * yes there's a user-space library that is proprietary *but* it qualifies under the GPL exemption clauses as a "System Library" * yes there is full *user* documentation available from ARM, as part of their standard SDK, etc. etc.
so, none of this is _actually_ anything to do with the SoC manufacturer themselves: all they really have to do is grab the Reference GPL "shim" Driver source code from ARM, make sure it compiles, grab the standard SDK from ARM and ship the binary proprietary libgl library along with making sure that android compiles against it, call the whole lot a "Reference Platform" and their job is done.
anyone who wants to step outside of those boundaries is pretty much on their own. but that's ok, because working out the above and taking it from there is a piece of cake compared to reverse-engineering actual hardware:)
Ok, so if I understand, the problem lies in the binary firmware blobs the ODM gets from the SoC maker, making it hell from that point on to install any distro lacking those drivers.
it's worse than that: you can't do security updates yourself, and if there's a bug you're screwed - you might as well throw the hardware away. the reason is that the ODMs are having such a hard time keeping hold of the limited supply of competent software engineers within china that they can't _do_ "updates": even if the factory asked for one, the ODM is forced to try to sell them the "latest hardware design" because the software engineer who did the firmware for the old device has quit and got a job somewhere else, better paid, with "old device X" on his CV!
And if they are included in the kernel without source code, it violates the kernel's GPL.
correct.
So the SoC maker doesn't violate the GPL, the ODM does,
actually... there are a number of SoC manufacturers that do. given the serious consequences to them of doing so (GPLv2 requires permission from *all* copyright holders for reinstatement of distribution rights), i am often stunned when i learn of a SoC manufacturer that is involved in GPL violations.
but the ODM never had the source to begin with.
often they do, but it's also often under NDA (which is a GPL violation by the SoC manufacturer). we have actually jeapordised a relationship with one ODM because we went "oi!" to the SoC manufacturer, pointing out the SoC manufacturer was in GPL violation, and this went down so badly that the SoC manufacturer refuses to provide that ODM with *any* source code! it's a real serious mess, basically.
I am beginning to understand what a mess the current fragmentation of designs has caused. I am glad there are people like you out there working towards bringing products to the market that preserve the spirit of true ownership, rather than feeling like a rented appliance.
appreciated.
I have been monitoring the Rasberry pi site for months waiting to grab a one from the first batch, but I will be keeping an eye on Rhombus tech now too. The PCMCIA approach is one I have not seen before though, interesting.
yeah - it's just at the right time. PCMCIA is dead, but with things like Conditional Access Modules for Satellite boxes, the actual PCMCIA connectors and assemblies are still being manufactured in mass-volume quantities. so we get the best of both worlds.
the thing is that a credit-card size is coincidentally the exact same size (to within a few millimetres) as a PCMCIA card. so the difference in price comes down to that of the CPU, and the Allwinner A10 is $7 in mass-volume. for a 1.5ghz Cortex A8. which is stunning. that means that qualcom's 700mhz ARM11 is going to be at least $12, possibly even as high as $15. it's really hard to see how a USA-based company, with the USA-based overheads, could possibly compete with the Taiwanese and China based SoC manufacturers.
that's a real pity. AlwaysInnovating touchbooks now i think the price is just too high compared to everything else, given that it uses overpriced TI CPUs. real pity.
What will it cost to do something with the dev module? At least through the network?
ok, one idea i'm advocating is to adapt arduino-like schematics to connect directly to the EOMA-PCMCIA-compliant interface. as such projects are usually a 2-layer board, very low-cost and the schematics are available under Open Source Licenses, it's a no-brainer. probably the best one to pick is the Leaflab's Maple: http://leaflabs.com/devices/maple/ because in mass-volume the CPU is around $1 to $1.50 (the 48-pin version not the 100-pin version!)
as this CPU is so low-cost, but importantly also so highly functional, its use substitutes and strategically "normalises" Motherboard designs. the plans being discussed at the moment include using the STM32F to do Audio (because of the D/A and A/D converters), battery monitoring (A/D converters), LCD Backlight control (PWM), resistive touchpanels (A/D converters again), keyboard matrix (8+8 GPIO) - someone's already written a mouse driver so at least that doesn't need to be done:)
so yes: if you're interested, look up the cost of arduino-like devices. at least for prototyping purposes you could just get an off-the-shelf leafpad maple and connect it directly to the EOMA-PCMCIA-compliant CPU card even with a few bits of wire, in a pinch.
anway, here's a link to some example motherboards that have been designed: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Example_Motherboards that includes a "micro" engineering board (that's nothing more complex than an adaptation of existing leafpad maple schematics) as well as something that's similar to the IMX53QSB, Beagleboard, Pandaboard and Origen etc.
Your price targets sound delightful. Might as well mark it up another $20 so you can fund the next version too. Or if the money could be spent on making it more rugged, that would be well-spent.
If the CPU is as fast as you say then there might be more interest in the dev module than you'd think.
yes, that's the plan:) would love to have some brainstorming ideas written by people on the possibilities, hmmm... let me just create a wiki page: http://rhombus-tech.net//community_ideas
GPL violations occur because the lowest-cost hardware is made by china factories who simply have zero software expertise. they just don't know enough to even *ask* for the GPL source code: they wouldn't know what to do with it if they received it: it's scarily-large, would consume vast amounts of their time and money (thus making them uncompetitive against all the other factories who will have also bought the exact same Reference Design), and there is a severe educational and economic shortage of software engineers in China anyway.
so, they ask an ODM for a ready-made solution, and they get one. any companies trying to deviate from the "solution" typically ship built-in webcams and microphones that don't even work because the binary-only firmware supplied by the ODM never had support for webcams or microphones!
but, you don't buy hardware from a china factory (because you can't "trust" them not to rip you off, right? and you don't want to deal with Customs and Import Tax, do you?) so you go to a retail store. but the retail store didn't get the hardware directly from china, they got it from a wholesale importer.
you see where this is going? neither the retailer, nor the wholesale importer, nor the factory that actually made the product ever saw, or understood, or even knew of the existence of, the GPL source code. yet, in strict accordance with the GPL you *have* to go "down the chain" of suppliers - you *cannot* go directly to the factory or even to the ODM - not least because you don't even know who they are!
second part of the answer is that each and every single device is radically different from any other device. there is no BIOS. there is no "commonality" between devices even with the same CPU! the GPL Linux Kernel is the *only* place where the information about the hardware is codified, in the form of "GPIO pin 12 fires up the WIFI in this tablet sold by this manufacturer" but "GPIO pin 87 fires up the WIFI in this completely different tablet, using the exact same CPU, from a different or even the same manufacturer".
this situation is causing absolute hell on earth for russell king, who is becoming increasingly despondent and depressed, as he has been "in the middle" of this for several years now: he's getting completely overwhelmed by the proliferation of ARM CPUs (over 1,000 now) multiplied by the number of devices using those CPUs (tens of thousands of designs). i have written up a sensible solution but getting through to linus and russell is somewhat challenging - http://lkcl.net/linux/linux-selfish.vs.cooperation.html
the other thing is that Android, which is a *userspace* set of applications *not* an "Operating System", is *not* GPL-based, it's Apache-2 licensed. then, also, there is a heavily-modified version of the Linux Kernel required for Android, and this version of the Linux Kernel *is* GPL-licensed. there is, understandably, considerable confusion and ignorance over this issue, right across the board.
so the problem really is the GPL violations on the Linux Kernel (including the one that is modified for use in Android, which is of course GPL-licensed), and also the GPL violations on the U-Boot Source Code, because this is where the hardware layout is "codified". without that information, it really is absolute hell on earth to find out what's going on. going back to about 2004, i've done reverse-engineering of about 12 ARM-based devices, now, so i know what it takes. you can't even compile up certain userspace applications, because the linux kernel header files are missing (/usr/include/linux).
then, you want to wipe the device and install debian? ok, so where in the NAND flash
ok there are two answer. the first is for the EOMA-compliant module *only*.
1) we'd like to keep it somewhere between $75 and $100 for the very early runs, and it looks like we're set to achieve that. it seriously depends on the quantities, and on how much profit people would like the CIC company to make (yes, CICs can work that way whereas Ltd Companies cannot be trusted with that kind of strategy).
the NREs (non-recurring expenses) by the factory will be about $2,000, and that excludes hardware engineer's time because we've done this "you don't charge us for hardware engineering time and we won't charge you for software engineering time" deal.
we have people committed to buying about 17 units so far: if that gets to 30 then the costs are down to $75 per unit (just for those initial 30). after that, there are no more NREs, and the unit cost can, assuming large volume, approach the mass-volume price of $15.
of course... that's excluding other parts which is answer 2:
2) it's best to go on mass-volume retail cost, unless you'd like to help dominic (debian developer, see debian-arm mailing list) make one using the EOMA-compliant CPU card which is where most of the difficult work (CPU-to-DDR RAM etc.) will already have been done.
mass-volume retail cost for something that even includes a capacitive touch panel can be as low as $130, but i know from experience that there's at least a 60% markup on the BOM, possibly even more. here's a link to a discussion: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/001136.html and please note that the example product will be yet _another_ GPL-violating tablet, absolutely guaranteed.
to work out the BOM you have to factor in the following costs, assuming mass-volume pricing: EOMA-PCMCIA-compliant CPU module about $15, 2000mAh battery $8, 7in 800x600 LCD $15, resistive touchpanel $5, main motherboard including WIFI module about $8, case (excluding *massive* NREs) about $3 - comes to a total of $39. yes, really - $39.
if you want a capacitive touchpanel instead, add an extra $15 because capacitive touchpanels, being also made of glass and having to be thicker than LCDs, are at least 25% more expensive than the LCD underneath them! but you can see, even with a capacitive touchpanel the BOM only comes to about $55.
so basically, you can see that a mass-volume retail cost of about $80 for a 7in tablet with the Allwinner A10 and a resistive touchpanel would be quite reasonable, and about $130 for one with a capacitive touchpanel would also be quite reasonable.
apologies for answering in a rather indirect and roundabout way, which i'm sure you would appreciate given that this is slashdot, and that i'm not working for a profit-maximising company that is primarily motivated to do anything including lie to you in order to get your money.
ah, sorry, correction: if you want libreoffice then you can't use the alwaysinnovating tablet - it has a maximum of 512mb of RAM. actually, you'd be hard pushed to find anything! even the CPU we've found maxes out at 1gb of RAM, and libreoffice requires an absolute minimum of 1.5gb of RAM. yes you can use NAND Flash as swap-space but you then risk destroying the NAND flash. yes you could use external USB memory sticks but they're typically slow as a dog. yes you could look for an x86-based tablet with 2gb of RAM but you'll have to shell out at least $500 retail to get one. you're caught between a rock and a hard place, basically! if you can bring your expecations down, such as by using the non-free docs.google.com online service, or perhaps abiword and gnumeric, you'll be ok.
The problem that's been made clear time and time again is that if you want low-cost mass-produced hardware, you normally have to go with GPL-violating products (see list here http://www.codon.org.uk/~mjg59/android_tablets/) and that means that you will spend the majority of your time reverse-engineering the product for anything between two weeks and two years, depending on luck and skill, before getting something useful. By the time you're done, the product is usually end-of-lifed: thus if it breaks, you're back to square one.
The reason for the GPL violations is that the low-cost China-based Factories simply have zero software skills: they're provided with binary-only firmware from an ODM who themselves usually had to sign an NDA from the SoC manufacturer, itself in direct violation of the GPL, in order to get access to the source code. Normally there's a chain of at least *five* companies with whom you have to negotiate with for several days or weeks - each - in order to explain the situation to them, against a precarious balance of them basically not giving a stuff because there's no financial incentive for them to give you anything at all: they're already making money, selling product, so why should they care?
thus, we logically concluded that the only way to get non-GPL-violating product out there is to go directly to the factories and be the supplier of their software.
so for the past two years i've been contacting and vetting China-based factories, directly, to find at least one which is prepared to work with us (RH Technology - http://www.rh-technology.com./ the basis of the deal is, "we won't charge you for software expertise if you won't charge us for hardware design costs", and after two years we finally found _one_ factory willing to do a deal, and are looking for more.
we've also found an absolutely great CPU, called the Allwinner A10, which in mass-volume quantities is only about $7: that means that a PCB similar to the raspberrypi with similar features can be made for about $15 (not $25) and, because the Allwinner CPU is an ARM Cortex A8 not an ARM11 it is at least three times quicker than the raspberrypi's CPU.
now we have at least 15 Debian Developers who are willing to support the project by buying beta hardware samples, and we're looking for more people to help support this effort, by committing to buy product (just like with the OpenPandora http://openpandora.org./ we have set up a CIC (http://en.wikipedia.org/wiki/Community_interest_company) because it's a better vehicle than a non-profit, charity or profit-maximising company. the CIC is called Rhombus Tech - http://rhombus-tech.net./
we also have the full support of the Board of Directors of the Allwinner CPU: they released full source code to us in advance. we've made it available and found it to compile successfully.
in-advance GPL-compliant hardware really is very very unusual. even USA-based companies typically release GPL source code on or after the day that a product is announced. Archos for example made a tablet that used the Telechips TCC8900 series of CPUs, and complied with the GPL (in direct violation of the standard NDA available at the time from the SoC manufacturer!).
other than that: about the only existing product on the market that i can really recommend to you is the alwaysinnovating touchbook: http://alwaysinnovating.com/ - it's about $300.
Nobody is buying a 350kg vehicle with room for 4. It's either too dangerous or too expensive.
both of those assumptions are wildly wrong! you simply cannot have a 350kg vehicle be more expensive than a 1500kg vehicle, just based on the quantity of materials alone - unless you've done something daft like use carbon fibre or a research-based material that is not yet in mass-production [which you simply do not need to do]
google "aixam mega", "ligier" and other Category L7E vehicles. google "gordon murray design".
french insurance company research shows that, actually, Category L7E "quadbike" cars paradoxically get into *less* accidents than traditional vehicles. my speculation on this is that these Category L7E vehicles look so different and the performance is so different that both the driver and other road users treat them with "kid gloves", which *automatically* calms everyone down.
if you still believe after reading the above that somehow 350kg vehicles are too dangerous or too expensive, go read up on someone who knows what he's talking about - gordon murray. http://www.wired.com/autopia/2011/09/gordon-murray-qa/
the article is entirely missing the point. range extension doesn't help if the vehicle into which the range extension is placed is massively inefficient. that means that you need to fix the problems associated with standard vehicle designs (box and wedge shapes) in order to get the aerodynamics losses cut by at least 50%, and you need to cut the weight by over 70% (1.5 to 2.0 tonnes down to 350kg) in order to be able to take advantage of hard compound "ECO" tyres, which would otherwise rapidly wear out on a "standard" car. once the aerodynamics are efficient and the weight is low, "range extension" actually provides enough power to run the vehicle pretty much directly. see http://lkcl.net/ev for details.
the law in the U.S. and the U.K and probably several countries as well is that it is ILLEGAL to even CLAIM that you can quotes cure cancer quotes.
one person who had some success with cancer treatment that did not involve pharmaceutical drugs mysteriously had his offices firebombed, received anonymous death threats that were not followed up by the police, and in the end was forced to move to mexico.
strangely (not really) he picked a piece of land that was specially surveyed at enormous cost for chemical toxicity levels, prior to purchase.
... it was very cool, especially combined with automated telnetting to KVM switches. at the HTTP console, just run a script that said "ok, power-cycle machine X, set it to PXE boot, rewrite the DHCP config (automatically), when it comes up it will load this OS":)
debian installer is very much misunderstood or at least underappreciated. i did a very very large (significant deviation / automated installation) system for automated customised installs of KDE desktop. some people said i would have been better off creating debian packages with postinst and preinst scripts, but i liked the convenience of being able to edit the shell scripts etc. etc. *without* having to run a debian package-create command. the results of the work are still here: http://lkcl.net/d-i/
anyway, you could quite easily use debian installer over PXE netboot - you just put the target repository that you want things to be loaded from into the standard kernel boot params (into the PXE config file) and debian installer will go "oh, i'm supposed to run in automated mode and to pick up scripts from http://lkcl.net/d-i let's do that then, eh?"
then you could have one automated installer which does the "wipe" process and another which does the "backup", and another which does the "reinstall". all specified via simple editing of PXE config files. just don't get them wrong, eh?:)
btw, in 2001 i was part of a team that did this sort of thing, entirely automated from a database. it was very cool. we even solved booting up and reinstalling NT systems (fast), by having a sysprep-enabled part-completed boot image that just needed finishing off.
any electronics manufacturing requires vast quantities of ultra-pure water, as well as large amounts of heavy metals and rare earth metals. pollution levels surrounding electronics factories, thousands of miles away from where you (the 1st World Reader) can actually see what's really going on, are beyond belief.
starting in about 2004 i bought, had destroyed and was forced to return, two removable DVD-RW drives. when i say destroyed i mean they were destroyed by their own firmware.
investigation showed that these DVD-RW drives had firmware that, unless a specific undocumented IDE command was not sent stating "this software is not pirated. this software is not pirated. this software is not pirated" the DVD-RW drive would destroy itself. one such drive failed to even *read* DVDs after performing this act of self-mutilation.
a french firm, who had a legitimate data backup system, even got caught out by this, and had to "negotiate" permission to gain access to the undocumented IDE commands.
the solution was laughably simple though. buy a standard desktop 5.25in DVD-RW drive and a portable IDE-to-USB adaptor. all that "security", negotiated by all those companies doing portable DVD-RW drives, and it was completely bypassable by just buying a DVD-RW drive from taiwan, korea or anywhere in the free world.
it's called skim-reading. i read a 300-page novel in about 2 hours, but that's a leisurely pace, for me. i can do 3 lines at a time if i want, just read the first words, jump several and diagonally down, hit the end of the 3rd line, repeat. eyes spot paragraph beginnings and ends and focus on those: this is standard stuff if you've ever read tony buzan's books, what's the big deal? i don't recall - ever - my lips moving, or there being any "sounds" occurring in my bwwaiiiin. yes there's a sort-of delay between words coming in and getting through but, isn't that normal?
6 months later i'll come back, read and enjoy the same book again, and find very occasionally that i missed something. perhaps i shouldn't ask, but how does everyone else "read"?
Slashdot Mirror
http://en.wikipedia.org/wiki/Jedi_census_phenomenon#United_Kingdom
teehee. 4th largest reported religion in England and Wales.
http://en.wikipedia.org/wiki/Jediism#Reaction - wonderful. a jedi knight gets thrown out of a job centre for not removing his hoodie. and a new law in 2010 *excludes* members of the Church of Jediism in the UK from protection against racial discrimination and hatred. wonderful.
i read somewhere that the number of people in the UK who declared themselves as Jedi Knights exceeds the number of people who declared themselves to be Sikhs. however, for some reason, Jediism - http://churchofjediism.org/ - isn't recognised as a religion in the UK.
How soon do you estimate that your company will be selling a computer based on the Allwinner A10?
lots of questions, vairon! :) let me do the best i can. an accurate answer is: we simply can't say. here's a more detailed answer.
based on the simplicity of the concept, which is more or less a cut/paste job for the hardware engineers in China to take the existing tried-and-tested Reference Design direct from AllWinner, if all went well and the hardware engineers were paid to work full-time on this (which they're not!) we could have first early beta boards in as little as 10 working days. then, on top of that, creating an appropriate motherboard is an even more trivial task, because it's only a 2-layer board. the complex part is in creating a case, where the lead times are at least 8 weeks for absolutely everyone in the industry, in China. the complexity and cost here is why we are avoiding, entirely, creating casework for the early prototypes, and are going for something that is more akin to beagleboards, origens, pandaboards and IMX53QSBs. the other option is to find pre-existing casework (for each type of device, be it nettop, laptop or tablet) and to adapt the motherboard to suit. there are thousands of such pre-existing designs available from the Industrial Flea Markets inside China, so it's worthwhile doing that.
so you can see: we'd like to get people involved and give them access to GPL-compliant hardware that, thanks to the modular EOMA-PCMCIA-based approach, will allow them to follow and upgrade from beta-level involvement to mass-volume products (instead of having to first buy a beagleboard for example, then throw it away and buy a mass-volume product with the exact same CPU that's probably GPL-violating and reverse-engineer it). primarily at this critical phase what we need is more Software (Libre) Developers.
Besides more RAM, SATA II interface and higher CPU speed is there anything else that you think will make it more less superior than the Raspberry Pi?
well that's hard to say, because the CPU on the raspberrypi is under strict NDA, and so are we, strictly speaking, with Allwinner. we _have_ however already released the GPL Linux Kernel Source code, so in some ways you're better off asking the raspberrypi team to answer this question.
based on the "publicly available" information about the raspberrypi, i can however make a comparison:
* the allwinner is a Cortex A8 up to 1.5ghz, and the rbpi's CPU is a much older 700mhz ARM11. immediately, therefore, you can say that the rbpi is never going to go above 512mb RAM, and it's also guaranteed to be at least 3x slower than the allwinner.
* the allwinner can take up to 1gb of 800mhz DDR3 RAM. the rbpi CPU i would be very surprised if it could take more than 400mhz DDR2 RAM: as it's reported as capable of HDMI video playback, that *might* be as high as 667mhz DDR2 RAM. the difference that the speed of the RAM makes, especially in these ARM CPUs which have relatively small 1st level caches, is absolutely staggering.
* the GPU from the rbpi CPU is apparently entirely new, proprietary and it looks like it's developed in-house at broadcom. no details available about it, other than "apparently it's fast". no source code, no libraries, no documentation - nothing. the GPU in the allwinner is the standard MALI 400. it's still proprietary, but it's a known quantity.
* the allwinner CPU actually has 4 SD 3.0 ultra-high-speed interfaces, 2 RGB/TTL interfaces (one of which, the pins can be swapped over to an IDE - PATA - interface), USB2-Host as well as USB-OTG, and much more. the kicker for me is the 8-way concurrent DMA-enabled NAND Flash Interface, that can do 8 16 or 32-bit addressing. the speed of read-writes through this would be absolutely phenomenal, and of serious concern in using the full capability would be exceeding the power budgets we've allocated for the EOMA-PCMCIA-compliant interface (5 watts maxim
nice idea. kinda a cross between a laptop and a desktop pc. i'll add it to the list. thanks!
achh, thanks - i thought i'd fixed that months ago!
bonch, i know you may believe that's ok, but it doesn't work that way. apple have violated so many peoples' trust and taken such complete utter control over the hardware and software that you *believe* you own that it's kinda scary to even hear you say "just get an ipad". apple even bought a company - outright - to make their own CPU so that they could do christ knows what - put in DRM or hardware-level monitoring and keystroke logging into the chip? everything about the ipad says to me to run like hell. oh, and i have a friend who works for foxconn - they know the prices of the ipad. it's only $150 FOB out of the factory in china: all the rest is profit for apple. you might want to think about that.
bmsleight - i'm maintaining the list by hand at the moment, if it gets big enough i'll start writing databases / use kickstarter / other but i'll endeavour to contact you via your homepage ok? if you're keeping an eye on this post, email me.
thanks.
l.
yes it's the standard MALI 400, so the situation is the same as for all other MALI GPU SoCs, which is worth repeating here because it's often misunderstood.
* yes there's a GPL "shim" driver available, which allows the userspace /usr/lib/libgl.so.2 library to communicate with the GPU
* yes there's a user-space library that is proprietary *but* it qualifies under the GPL exemption clauses as a "System Library"
* yes there is full *user* documentation available from ARM, as part of their standard SDK, etc. etc.
so, none of this is _actually_ anything to do with the SoC manufacturer themselves: all they really have to do is grab the Reference GPL "shim" Driver source code from ARM, make sure it compiles, grab the standard SDK from ARM and ship the binary proprietary libgl library along with making sure that android compiles against it, call the whole lot a "Reference Platform" and their job is done.
anyone who wants to step outside of those boundaries is pretty much on their own. but that's ok, because working out the above and taking it from there is a piece of cake compared to reverse-engineering actual hardware :)
Ok, so if I understand, the problem lies in the binary firmware blobs the ODM gets from the SoC maker, making it hell from that point on to install any distro lacking those drivers.
it's worse than that: you can't do security updates yourself, and if there's a bug you're screwed - you might as well throw the hardware away. the reason is that the ODMs are having such a hard time keeping hold of the limited supply of competent software engineers within china that they can't _do_ "updates": even if the factory asked for one, the ODM is forced to try to sell them the "latest hardware design" because the software engineer who did the firmware for the old device has quit and got a job somewhere else, better paid, with "old device X" on his CV!
And if they are included in the kernel without source code, it violates the kernel's GPL.
correct.
So the SoC maker doesn't violate the GPL, the ODM does,
actually... there are a number of SoC manufacturers that do. given the serious consequences to them of doing so (GPLv2 requires permission from *all* copyright holders for reinstatement of distribution rights), i am often stunned when i learn of a SoC manufacturer that is involved in GPL violations.
but the ODM never had the source to begin with.
often they do, but it's also often under NDA (which is a GPL violation by the SoC manufacturer). we have actually jeapordised a relationship with one ODM because we went "oi!" to the SoC manufacturer, pointing out the SoC manufacturer was in GPL violation, and this went down so badly that the SoC manufacturer refuses to provide that ODM with *any* source code! it's a real serious mess, basically.
I am beginning to understand what a mess the current fragmentation of designs has caused. I am glad there are people like you out there working towards bringing products to the market that preserve the spirit of true ownership, rather than feeling like a rented appliance.
appreciated.
I have been monitoring the Rasberry pi site for months waiting to grab a one from the first batch, but I will be keeping an eye on Rhombus tech now too. The PCMCIA approach is one I have not seen before though, interesting.
yeah - it's just at the right time. PCMCIA is dead, but with things like Conditional Access Modules for Satellite boxes, the actual PCMCIA connectors and assemblies are still being manufactured in mass-volume quantities. so we get the best of both worlds.
the thing is that a credit-card size is coincidentally the exact same size (to within a few millimetres) as a PCMCIA card. so the difference in price comes down to that of the CPU, and the Allwinner A10 is $7 in mass-volume. for a 1.5ghz Cortex A8. which is stunning. that means that qualcom's 700mhz ARM11 is going to be at least $12, possibly even as high as $15. it's really hard to see how a USA-based company, with the USA-based overheads, could possibly compete with the Taiwanese and China based SoC manufacturers.
that's a real pity. AlwaysInnovating touchbooks now i think the price is just too high compared to everything else, given that it uses overpriced TI CPUs. real pity.
apologies - you're right! i must have looked at firefox and got confused. yes, 576mb RAM - remember that unless you want the NAND flash to be destroyed you really have to run without swap space on these low-cost ARM devices. top - 15:03:03 up 3 days, 4:34, 19 users, load average: 0.21, 0.16, 0.14 Tasks: 214 total, 3 running, 203 sleeping, 8 stopped, 0 zombie Cpu(s): 49.5%us, 1.2%sy, 0.0%ni, 49.2%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2046104k total, 1853840k used, 192264k free, 14644k buffers Swap: 7811068k total, 471372k used, 7339696k free, 275676k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9111 lkcl 20 0 1683m 832m 21m R 96 41.7 1117:47 firefox-bin 3659 root 20 0 413m 124m 3796 S 5 6.2 86:26.15 Xorg 26440 lkcl 20 0 576m 95m 63m S 2 4.8 0:02.27 soffice.bin
I appreciate the fullness of the answer.
no problem.
What will it cost to do something with the dev module? At least through the network?
ok, one idea i'm advocating is to adapt arduino-like schematics to connect directly to the EOMA-PCMCIA-compliant interface. as such projects are usually a 2-layer board, very low-cost and the schematics are available under Open Source Licenses, it's a no-brainer. probably the best one to pick is the Leaflab's Maple: http://leaflabs.com/devices/maple/ because in mass-volume the CPU is around $1 to $1.50 (the 48-pin version not the 100-pin version!)
as this CPU is so low-cost, but importantly also so highly functional, its use substitutes and strategically "normalises" Motherboard designs. the plans being discussed at the moment include using the STM32F to do Audio (because of the D/A and A/D converters), battery monitoring (A/D converters), LCD Backlight control (PWM), resistive touchpanels (A/D converters again), keyboard matrix (8+8 GPIO) - someone's already written a mouse driver so at least that doesn't need to be done :)
so yes: if you're interested, look up the cost of arduino-like devices. at least for prototyping purposes you could just get an off-the-shelf leafpad maple and connect it directly to the EOMA-PCMCIA-compliant CPU card even with a few bits of wire, in a pinch.
anway, here's a link to some example motherboards that have been designed: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Example_Motherboards
that includes a "micro" engineering board (that's nothing more complex than an adaptation of existing leafpad maple schematics) as well as something that's similar to the IMX53QSB, Beagleboard, Pandaboard and Origen etc.
Your price targets sound delightful. Might as well mark it up another $20 so you can fund the next version too. Or if the money could be spent on making it more rugged, that would be well-spent.
If the CPU is as fast as you say then there might be more interest in the dev module than you'd think.
yes, that's the plan :) would love to have some brainstorming ideas written by people on the possibilities, hmmm... let me just create a wiki page: http://rhombus-tech.net//community_ideas
ok, i've written about this on a number of occasions, such as this one http://lkcl.net/linux/ideal-vs-reality.of.product.development.html but it's definitely worthwhile repeating things here, in this context.
GPL violations occur because the lowest-cost hardware is made by china factories who simply have zero software expertise. they just don't know enough to even *ask* for the GPL source code: they wouldn't know what to do with it if they received it: it's scarily-large, would consume vast amounts of their time and money (thus making them uncompetitive against all the other factories who will have also bought the exact same Reference Design), and there is a severe educational and economic shortage of software engineers in China anyway.
so, they ask an ODM for a ready-made solution, and they get one. any companies trying to deviate from the "solution" typically ship built-in webcams and microphones that don't even work because the binary-only firmware supplied by the ODM never had support for webcams or microphones!
but, you don't buy hardware from a china factory (because you can't "trust" them not to rip you off, right? and you don't want to deal with Customs and Import Tax, do you?) so you go to a retail store. but the retail store didn't get the hardware directly from china, they got it from a wholesale importer.
you see where this is going? neither the retailer, nor the wholesale importer, nor the factory that actually made the product ever saw, or understood, or even knew of the existence of, the GPL source code. yet, in strict accordance with the GPL you *have* to go "down the chain" of suppliers - you *cannot* go directly to the factory or even to the ODM - not least because you don't even know who they are!
second part of the answer is that each and every single device is radically different from any other device. there is no BIOS. there is no "commonality" between devices even with the same CPU! the GPL Linux Kernel is the *only* place where the information about the hardware is codified, in the form of "GPIO pin 12 fires up the WIFI in this tablet sold by this manufacturer" but "GPIO pin 87 fires up the WIFI in this completely different tablet, using the exact same CPU, from a different or even the same manufacturer".
this situation is causing absolute hell on earth for russell king, who is becoming increasingly despondent and depressed, as he has been "in the middle" of this for several years now: he's getting completely overwhelmed by the proliferation of ARM CPUs (over 1,000 now) multiplied by the number of devices using those CPUs (tens of thousands of designs). i have written up a sensible solution but getting through to linus and russell is somewhat challenging - http://lkcl.net/linux/linux-selfish.vs.cooperation.html
the other thing is that Android, which is a *userspace* set of applications *not* an "Operating System", is *not* GPL-based, it's Apache-2 licensed. then, also, there is a heavily-modified version of the Linux Kernel required for Android, and this version of the Linux Kernel *is* GPL-licensed. there is, understandably, considerable confusion and ignorance over this issue, right across the board.
so the problem really is the GPL violations on the Linux Kernel (including the one that is modified for use in Android, which is of course GPL-licensed), and also the GPL violations on the U-Boot Source Code, because this is where the hardware layout is "codified". without that information, it really is absolute hell on earth to find out what's going on. going back to about 2004, i've done reverse-engineering of about 12 ARM-based devices, now, so i know what it takes. you can't even compile up certain userspace applications, because the linux kernel header files are missing (/usr/include/linux).
then, you want to wipe the device and install debian? ok, so where in the NAND flash
ok there are two answer. the first is for the EOMA-compliant module *only*.
1) we'd like to keep it somewhere between $75 and $100 for the very early runs, and it looks like we're set to achieve that. it seriously depends on the quantities, and on how much profit people would like the CIC company to make (yes, CICs can work that way whereas Ltd Companies cannot be trusted with that kind of strategy).
the NREs (non-recurring expenses) by the factory will be about $2,000, and that excludes hardware engineer's time because we've done this "you don't charge us for hardware engineering time and we won't charge you for software engineering time" deal.
we have people committed to buying about 17 units so far: if that gets to 30 then the costs are down to $75 per unit (just for those initial 30). after that, there are no more NREs, and the unit cost can, assuming large volume, approach the mass-volume price of $15.
of course... that's excluding other parts which is answer 2:
2) it's best to go on mass-volume retail cost, unless you'd like to help dominic (debian developer, see debian-arm mailing list) make one using the EOMA-compliant CPU card which is where most of the difficult work (CPU-to-DDR RAM etc.) will already have been done.
mass-volume retail cost for something that even includes a capacitive touch panel can be as low as $130, but i know from experience that there's at least a 60% markup on the BOM, possibly even more. here's a link to a discussion: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/001136.html and please note that the example product will be yet _another_ GPL-violating tablet, absolutely guaranteed.
to work out the BOM you have to factor in the following costs, assuming mass-volume pricing: EOMA-PCMCIA-compliant CPU module about $15, 2000mAh battery $8, 7in 800x600 LCD $15, resistive touchpanel $5, main motherboard including WIFI module about $8, case (excluding *massive* NREs) about $3 - comes to a total of $39. yes, really - $39.
if you want a capacitive touchpanel instead, add an extra $15 because capacitive touchpanels, being also made of glass and having to be thicker than LCDs, are at least 25% more expensive than the LCD underneath them! but you can see, even with a capacitive touchpanel the BOM only comes to about $55.
so basically, you can see that a mass-volume retail cost of about $80 for a 7in tablet with the Allwinner A10 and a resistive touchpanel would be quite reasonable, and about $130 for one with a capacitive touchpanel would also be quite reasonable.
apologies for answering in a rather indirect and roundabout way, which i'm sure you would appreciate given that this is slashdot, and that i'm not working for a profit-maximising company that is primarily motivated to do anything including lie to you in order to get your money.
ah, sorry, correction: if you want libreoffice then you can't use the alwaysinnovating tablet - it has a maximum of 512mb of RAM. actually, you'd be hard pushed to find anything! even the CPU we've found maxes out at 1gb of RAM, and libreoffice requires an absolute minimum of 1.5gb of RAM. yes you can use NAND Flash as swap-space but you then risk destroying the NAND flash. yes you could use external USB memory sticks but they're typically slow as a dog. yes you could look for an x86-based tablet with 2gb of RAM but you'll have to shell out at least $500 retail to get one. you're caught between a rock and a hard place, basically! if you can bring your expecations down, such as by using the non-free docs.google.com online service, or perhaps abiword and gnumeric, you'll be ok.
Here's the thread on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00008.html and the corresponding one on arm-netbook: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/thread.html
The problem that's been made clear time and time again is that if you want low-cost mass-produced hardware, you normally have to go with GPL-violating products (see list here http://www.codon.org.uk/~mjg59/android_tablets/) and that means that you will spend the majority of your time reverse-engineering the product for anything between two weeks and two years, depending on luck and skill, before getting something useful. By the time you're done, the product is usually end-of-lifed: thus if it breaks, you're back to square one.
The reason for the GPL violations is that the low-cost China-based Factories simply have zero software skills: they're provided with binary-only firmware from an ODM who themselves usually had to sign an NDA from the SoC manufacturer, itself in direct violation of the GPL, in order to get access to the source code. Normally there's a chain of at least *five* companies with whom you have to negotiate with for several days or weeks - each - in order to explain the situation to them, against a precarious balance of them basically not giving a stuff because there's no financial incentive for them to give you anything at all: they're already making money, selling product, so why should they care?
thus, we logically concluded that the only way to get non-GPL-violating product out there is to go directly to the factories and be the supplier of their software.
so for the past two years i've been contacting and vetting China-based factories, directly, to find at least one which is prepared to work with us (RH Technology - http://www.rh-technology.com./ the basis of the deal is, "we won't charge you for software expertise if you won't charge us for hardware design costs", and after two years we finally found _one_ factory willing to do a deal, and are looking for more.
we've also found an absolutely great CPU, called the Allwinner A10, which in mass-volume quantities is only about $7: that means that a PCB similar to the raspberrypi with similar features can be made for about $15 (not $25) and, because the Allwinner CPU is an ARM Cortex A8 not an ARM11 it is at least three times quicker than the raspberrypi's CPU.
now we have at least 15 Debian Developers who are willing to support the project by buying beta hardware samples, and we're looking for more people to help support this effort, by committing to buy product (just like with the OpenPandora http://openpandora.org./ we have set up a CIC (http://en.wikipedia.org/wiki/Community_interest_company) because it's a better vehicle than a non-profit, charity or profit-maximising company. the CIC is called Rhombus Tech - http://rhombus-tech.net./
we also have the full support of the Board of Directors of the Allwinner CPU: they released full source code to us in advance. we've made it available and found it to compile successfully.
in-advance GPL-compliant hardware really is very very unusual. even USA-based companies typically release GPL source code on or after the day that a product is announced. Archos for example made a tablet that used the Telechips TCC8900 series of CPUs, and complied with the GPL (in direct violation of the standard NDA available at the time from the SoC manufacturer!).
other than that: about the only existing product on the market that i can really recommend to you is the alwaysinnovating touchbook: http://alwaysinnovating.com/ - it's about $300.
Nobody is buying a 350kg vehicle with room for 4. It's either too dangerous or too expensive.
both of those assumptions are wildly wrong! you simply cannot have a 350kg vehicle be more expensive than a 1500kg vehicle, just based on the quantity of materials alone - unless you've done something daft like use carbon fibre or a research-based material that is not yet in mass-production [which you simply do not need to do]
google "aixam mega", "ligier" and other Category L7E vehicles. google "gordon murray design".
french insurance company research shows that, actually, Category L7E "quadbike" cars paradoxically get into *less* accidents than traditional vehicles. my speculation on this is that these Category L7E vehicles look so different and the performance is so different that both the driver and other road users treat them with "kid gloves", which *automatically* calms everyone down.
if you still believe after reading the above that somehow 350kg vehicles are too dangerous or too expensive, go read up on someone who knows what he's talking about - gordon murray. http://www.wired.com/autopia/2011/09/gordon-murray-qa/
the article is entirely missing the point. range extension doesn't help if the vehicle into which the range extension is placed is massively inefficient. that means that you need to fix the problems associated with standard vehicle designs (box and wedge shapes) in order to get the aerodynamics losses cut by at least 50%, and you need to cut the weight by over 70% (1.5 to 2.0 tonnes down to 350kg) in order to be able to take advantage of hard compound "ECO" tyres, which would otherwise rapidly wear out on a "standard" car. once the aerodynamics are efficient and the weight is low, "range extension" actually provides enough power to run the vehicle pretty much directly. see http://lkcl.net/ev for details.
the law in the U.S. and the U.K and probably several countries as well is that it is ILLEGAL to even CLAIM that you can quotes cure cancer quotes.
one person who had some success with cancer treatment that did not involve pharmaceutical drugs mysteriously had his offices firebombed, received anonymous death threats that were not followed up by the police, and in the end was forced to move to mexico.
strangely (not really) he picked a piece of land that was specially surveyed at enormous cost for chemical toxicity levels, prior to purchase.
... it was very cool, especially combined with automated telnetting to KVM switches. at the HTTP console, just run a script that said "ok, power-cycle machine X, set it to PXE boot, rewrite the DHCP config (automatically), when it comes up it will load this OS" :)
debian installer is very much misunderstood or at least underappreciated. i did a very very large (significant deviation / automated installation) system for automated customised installs of KDE desktop. some people said i would have been better off creating debian packages with postinst and preinst scripts, but i liked the convenience of being able to edit the shell scripts etc. etc. *without* having to run a debian package-create command. the results of the work are still here: http://lkcl.net/d-i/
anyway, you could quite easily use debian installer over PXE netboot - you just put the target repository that you want things to be loaded from into the standard kernel boot params (into the PXE config file) and debian installer will go "oh, i'm supposed to run in automated mode and to pick up scripts from http://lkcl.net/d-i let's do that then, eh?"
then you could have one automated installer which does the "wipe" process and another which does the "backup", and another which does the "reinstall". all specified via simple editing of PXE config files. just don't get them wrong, eh? :)
btw, in 2001 i was part of a team that did this sort of thing, entirely automated from a database. it was very cool. we even solved booting up and reinstalling NT systems (fast), by having a sysprep-enabled part-completed boot image that just needed finishing off.
any electronics manufacturing requires vast quantities of ultra-pure water, as well as large amounts of heavy metals and rare earth metals. pollution levels surrounding electronics factories, thousands of miles away from where you (the 1st World Reader) can actually see what's really going on, are beyond belief.
starting in about 2004 i bought, had destroyed and was forced to return, two removable DVD-RW drives. when i say destroyed i mean they were destroyed by their own firmware.
investigation showed that these DVD-RW drives had firmware that, unless a specific undocumented IDE command was not sent stating "this software is not pirated. this software is not pirated. this software is not pirated" the DVD-RW drive would destroy itself. one such drive failed to even *read* DVDs after performing this act of self-mutilation.
a french firm, who had a legitimate data backup system, even got caught out by this, and had to "negotiate" permission to gain access to the undocumented IDE commands.
the solution was laughably simple though. buy a standard desktop 5.25in DVD-RW drive and a portable IDE-to-USB adaptor. all that "security", negotiated by all those companies doing portable DVD-RW drives, and it was completely bypassable by just buying a DVD-RW drive from taiwan, korea or anywhere in the free world.
it's called skim-reading. i read a 300-page novel in about 2 hours, but that's a leisurely pace, for me. i can do 3 lines at a time if i want, just read the first words, jump several and diagonally down, hit the end of the 3rd line, repeat. eyes spot paragraph beginnings and ends and focus on those: this is standard stuff if you've ever read tony buzan's books, what's the big deal? i don't recall - ever - my lips moving, or there being any "sounds" occurring in my bwwaiiiin. yes there's a sort-of delay between words coming in and getting through but, isn't that normal?
6 months later i'll come back, read and enjoy the same book again, and find very occasionally that i missed something. perhaps i shouldn't ask, but how does everyone else "read"?