amount of time taken asking questions: 0 seconds. ability read and follow instructions: 0%. ability to complain: 100%. ability to file bugreport or contact forum or mailing lists requesting detailed instructions: 0%.
_come_ on, dude, you know the drill. if you can't get something working, *ask the developers*. give them detailed reports, help them diagnose the problem with the build instructions, so that they can be improved. over time, things get fixed, yeah?
what would you have the developers do, huh? if you understand what openembedded's "bitbake" command is really about, and understand how powerful it is, you wouldn't be complaining, you'd be somewhere in awe or possibly shock. openembedded has a bang-per-buck ratio that's wayyy above anything else available from the free software community. gentoo's portage, buildroot, debian's build system - they're all child's toys by comparison.
tell me if you know of any other cross-build system that, in order to correctly configure a package and cross-compile it, fires up a *native* gcc compiler and runs the autoconf configure script in a qemu command-line virtual environment. now that's just so fucking smart - it solves *all* the problems that all the other "autoconf cache" broken workarounds just can't get right.
the people who came up with openembedded are just... unbelievably smart people. they know that they don't have a lot of resources, so they come up with solutions that make up for it, and do the work in an automated fashion. they've been at this for over 10 years, so cut them some slack, ok?
having read all of the asimov books, including those written under commission by the Asimov Estate, i'm a bit concerned about this obsession with the famous "3 Laws of Robotics". later books came up with the "New Law" Robots, and several books covered a character called "Caliban", who was a robotic experimental "No Law" Robot that was framed for murder, escaped, and through naive, direct and untainted access to the world on which it was created, came up with its own ethics - its own "Laws", in pretty much exactly the same way that any intelligent human would.
my concern therefore stems from Asimov's own concerns, that the 3 Laws of Robotics resulted in a "coddled society". the "Giskardian" Robots had a Zeroth Law imprinted on them, via a Robot named "Giskard" who was accidentally one of the first telepathic robots, and possessed the ability to telepathically imprint thought patterns onto other beings (including other robots). R. Daneel, a humaniform robot, was the first to be so imprinted, and the implication from other books is that R. Daneel lived about 30,000 years and saw through - engineered and directed - the *entire* Foundation. the scope of Asimov's work is just... breathtaking when you read all the books.
the Zeroth Law Robots (Giskardians) interfered with humanity's evolution, for their own good; the 3 Law Robots (Calvanists) attempted to serve individual humans as best they could within the rigid confines of their programming. The key here is that both groups *interfered* with human development, as a direct result of their programming.
so the point is: i don't believe that it's a good idea to start advocating the 3 Laws as the absolute be-all and end-all answer as to how to shape and direct the creation of robotic intelligence. Asimov's own stories tell us a dozen or more ways in which the 3 Laws can go horribly wrong. i think we can decide for ourselves how best to create intelligent robots, thank you.
yeah. in an effort to throw trackers off the scent, the criminal mastermind selected "Arabic" as the language and "Cyrillic" for the keyboard. now the DHS and the Secret Service's heads have exploded in their efforts to understand why their terrorist suspect would appear to be so intelligent as to understand two foreign languages but would be so stupid as to format the wrong drive.
Wait, so the ARM Cortex A8 architecture is completely open while the Raspberry Pi's ARM11 architecture isn't? I'm not sure I follow...
Otherwise, this project looks very interesting!
ah sorry, you've misunderstood. SoCs are far more than just the CPU Architecture that's used to power them. if you look at pictures of silicon layouts, you'll see that the actual CPU part is only about 1% of the whole SoC. a whopping 10% is dedicated to the I/O pads, to get enough power to push the lines from 0 to 1 and vice-versa at the kinds of speeds people need. 20% or more is typically 1st level cache. peripherals is about 5% of the silicon area, and routing (buses which can sometimes be 512 bits wide) consumes vast areas.
also: if you look at the functional block diagrams of SoCs, you'll see that the actual CPU, usually in the centre, takes up something like 5% of the picture; the centre is surrounded by dozens of peripherals.
in other words, the actual CPU - ARM11 or Cortex A8, it doesn't really matter - is actually very insignificant. after all, the only thing it does is run general-purpose instructions. it's what that CPU is surrounded by - within that black box - that makes up the whole story.
in the case of the broadcom chip, the GPU is entirely proprietary. it's utterly, utterly secret. absolutely no details are provided about its operation, whatsoever. yes, sure, it has an opengl interface, but we do not know if it does more than that. it cannot be trusted. broadcom cannot be trusted. for all we know, it is storing information on the use of the chip so that if broadcom gain access to it and run a special sequence of commands, it tells them exactly what the chip has been used for. we just don't know.
the short version is: you're confusing an architecture with a system that *uses* that architecture as one of its components. just because that one component happens to be open does not mean that the details of the entire system are also open. in the case of the broadcom chip, we know for a fact that it is definitely NOT open, and that's what's pissing people off.
there are quite a lot of other points made in the original post - mention of patents, mention of cost etc etc - so it is quite easy to miss the key words "black box". focussing on the patents themselves in isolation is missing the point. it's *NOT* about the patents. it's about the fact that the device is a "black box".
so it depends on whether you consider hypocrisy to be important or not. many people do not. what broadcom is really saying is "we support education and learning using our products because it's a good wheeze that makes us money and makes us look good at the same time. but you're not permitted to learn about this, this or this feature: we're keeping that entirely secret. if you want the source code, you can fuck off".
the CPU being used has a rather unique design: the GPU boots up the CPU. the fact that the boot-up sequence is critically dependent on a proprietary blob to which no-one is given access REALLY pisses people off. privacy concerns, education hypocrisy: the works.
that's what we're doing with the http://rhombus-tech.net/ project. the scope of the project has the goals of the raspberrypi foundation as a subset; CPUs that we are actively pursuing have to have full GPL compliance, and are as open as possible / practical. where binary blobs exist, reverse-engineered alternatives are encouraged to be created. the first CPU Card is based on the Allwinner A10 (ARM Cortex A8, 1ghz, overclockable to 1.5ghz). the binary startup blob which is essential to set the DDR3 RAM timings before continuing with the 2nd phase of the boot process was reverse-engineered a few months ago; the MALI GPU has the limadriver project on the case; efforts are underway to investigate the proprietary video hardware encode/decode engine. we were given full access to the GPL kernel and u-boot sources within 48 hours of asking (even though we did not have a GPL compliance request outstanding).
answering your question, archiebunker: designing something better is a bit harder than you might imagine. full access to technical datasheets is often denied: you are literally at the mercy of the SoC vendor and if they don't like the way you dress, or smell, or if you're not one of their pally-pal pals you can flat-out forget gaining access to the documentation. one of the key reasons is that they simply don't know if you have the expertise, or if you can be trusted not to pass on information to their competitors. so, if it turns out that you don't have the expertise, and you have to come to them with questions, you just cost them money. if you leak information to their competitors, you REALLY just cost them money - serious money.
so what we're doing with the EOMA-68 initiative is to make the hard part - the CPU+DDR3+NAND - be "just a mass-produced component" that you can literally buy off-the-shelf in a retail store. if it comes in a case, you get access to the EOMA-68 interfaces and whatever else the CPU Card has on the user-facing front edge; if you buy it without the case, you also get access to the internal jumpers and additional connectors, for educational and R&D purposes as well as factory-install purposes.
we're getting there. it's been a long haul, and we will not stop. the team behind the initiative will be sticking with this for the next decade, keeping it constantly up-to-date and ensuring that new CPU Cards are always available.
I'd like to see a well-founded analysis of the differences of Atom and ARM, but superficial statements like "RISC is bad" don't cut it.
i've covered this a couple of times on slashdot: simply put it's down to the differences in execution speed vs the storage size of those instructions. slightly interfering with that is of course the sizes of the L1 and L2 caches, but that's another story.
in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
now, as we well know, power consumption is a square law of the clock rate. so in a rough comparison, in the same geometry (e.g. 45nm), that 1.6ghz CPU is going to be roughly TEN times more power consumption than that dual-core ARM Cortex A9. e.g. that 500mhz dual-core Cortex A9 is going to be about 0.5 watts (roughly true) and the 1.6ghz Intel Atom is going to be about 5 watts (roughly true).
what that means is that x86 is basicallly onto a losing game.... period. the only way to "win" is for Intel and AMD to have access to geometries that are at least 2x better than anything else available in the world. each new geometry that comes out is not going to *stay* 2x better for very long. when everyone has access to 45nm, intel and AMD have to have access to 22nm or better... *at the same time*. not "in 6-12 months time", but *at the same time*. when everyone else has access to 28nm, intel and AMD have to have access to 14nm or better.
intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.
As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers.
yes. absolutely. you've put your finger on the problem. i've mentioned this before, and... hang on, i think i even wrote a message to linus torvalds but of course, he's far too busy to read it:) 1sec let me see if i can find it.... hard to find hints, try this http://lkcl.net/linux/eoma.initiative.txt but also go (briefly!) over some of the others: http://lkcl.net/linux
the point is that each ARM processor is *wildly* different from all other ARM processors. linus doesn't understand this. he was at a meeting of all the arch maintainers and said "over half of you are from the ARM arch. go away! get yourselves sorted out!" and what he doesn't understand is that that's an impossible task. not even "device tree" will help solve it.
because all these ARM (and MIPS) processors are so heavily-integrated, there can NEVER BE a "common BIOS", and the level of commonality between each of the processors is so small that it forces the linux kernel to *become* the BIOS, effectively. i actually recommended at one point that the linux kernel be split down into separate projects: core, architecture support and device drivers. and i do _mean_ separate projects, each with their own separate source tree and maintainers.
then, not only is there virtually no common code between each of the processors (hundreds of them... and increasing) but then, precisely because of this total lack of commonality, and precisely because of the practice of "integrating" the CPU onto the motherboard, each device that *uses* one of these CPUs is UTTERLY UNIQUE.
let that sink in for a second.
every single piece of hardware which has an ARM or MIPS processor has UTTERLY UNIQUE code which *HARD-CODES* the ENTIRE device driver layout.
no wonder they're pushing this thing called "device tree" so hard, as it's believed that it will solve the problem: it won't. all it will do is move the problem out of *some* of the linux kernel source code, and will move the problem into the device-tree specification files, whilst also at the same time complicating the development of the device drivers themselves.... but it doesn't end there. whereas in the x86 world, there's a BIOS which sorts out the boot process, there's... nothing in the ARM or MIPS world. so someone decided it would be a good idea, instead of using kexec, to create "u-boot". u-boot is a bastardisation of libc and bits of the linux kernel, combined into one application, allowing you to write very basic c applications, enough to initialise the low-level hardware and give you a few options. the problem is: it pulls in "bits of the linux kernel", in order to start up the hardware. can you spell "code duplication" and "maintenance nightmare?".
so this is one of the real reasons why we've come up with the EOMA initiative: to solve not only the GPL violations problem but also to help reduce the "device-driver nightmare" to manageable levels. think about it: rather than it being a "N CPUs" *times* "M hardware products", by splitting the products into modules along a series of "Bus-level" interfaces (SATA, USB, Eth, I2C), the linux kernel source code to support EOMA can be a "N CPUs" *plus* "M hardware products" *plus* a little bit of library overhead.
you see how powerful that is? we recognise that x86 is much, much easier to develop linux kernel support for, mostly because of common BIOS support but more because of the common dynamic "Buses" like PCI, PCIe, USB2, Firewire etc. all of which provide a clean bre
Serious question. Why would vendors support such an approach?
we have one vendor who *is* fully behind it. it took them a long time, a whiteboard and a lot of hand-waving but they got it. it was an amazing meeting, after 2 years of them not getting it, where they suddenly got excited and went, "hey! we have an all-in-one PC product: we could... we could... convert that to a TV or upgrade it by just changing the CPU Card!" and it was a eureka moment - such a relief:)
but the key for them is that they are an assembly company rather than a manufacturing company. a whopping half a MILLION square metres factory space screwdriver / assembly company. the modularity of the approach we've come up is absolutely perfect for them. other companies supply the EOMA-68 PCBs (a million at a time); they put them into the cases. other companies supply them with the parts needed for a laptop (a million at a time); they put them together.
one absolutely jammy coincidence for us is that they'd *just* been asked to assemble 20 million+ PCMCIA 3G modems for a customer of theirs. note: PCMCIA modems. exactly the same size and form-factor and even exactly the same components (PCMCIA connector) as the EOMA-68 CPU Card.
the problem for them right now is that their "assembly" approach, combined with the well-known *insanely* low margins in the x86 laptop business, leaves them completely unprofitable. all their suppliers of the parts make the margins; they don't. this is the situation that has to change, and we're privileged to be able to offer them a solution that they've accepted.
ultimately, i see this approach empowering smaller 3rd party companies to be able to re-enter the markets that they've been squeezed out of by the ever-decreasing margins of the PC business. the hard part, technically is the CPU Card. the most expensive part is the casework. not exactly sure how to deal with that: 3D printers sort-of spring to mind... anyway, just a thought.
I am not familiar with UK laws at the time, but it seems unlikely this was the fastest way of dealing with the problem. It sounds nice when told that way, but one could just as easily state that a third party discovery request would be a known stalemate, yet it was chosen over going directly to the people in charge of regulating imports, drugs, and/or murder and let them deal with it.
In other words, a third party request from police or other Executive players would have likely been granted quickly.
NO. Anthony Pickford's strategy was the reason *WHY* it is now Law in the UK that 3rd Party Discovery Requests must be complied with. before this case, if a 3rd party was requested, during the discovery phase, to provide information, there was *no* reason why or law compelling the 3rd party to comply.
look him up. of 36 changes to UK Law of the past 50 years, a full *EIGHTEEN* of those changes are - were - down to my uncle. the intelligent, gifted, angry, intolerant and vindictive silly man. *sigh*. he was responsible for example for a change to the "Dangerous Dogs" Act. his neighbour's very expensive, very loving and very beautiful japanese dog was forced to be muzzled but it had breathing difficulties and would have died if it was forced to wear a restrictive device: he took the case all the way through to the House of Lords and got the law changed to be more reasonable and sane.
anyway: whilst it sounds nice to make a third party request to "the police or to other executive players", if you think that through for a minute you'll find that it's not as effective. the *police* weren't the ones with the import records, were they? these "executive players" weren't the ones with the import records, were they? no - that would have been *abdicating* responsibility for dealing with the problem, wouldn't it? and they would have had to "engage" those people, and risk *NOT* being able to get them interested, get through their bureaucratic minds that action needed to be taken FAST, to stop people from being killed, wouldn't they?
instead, they went directly for the people who actually had the information.
This sounds like one of those TV Tropes where the main character thinks they are the only person who can solve the problem
:) well, he did solve it. he was one of these very intelligent and very forceful people who got shit done, and, sadly, despised anyone who was either unintelligent or weak in his view. he was charming to speak with during the afternoon and evening, in a social context, but an absolute fucking nightmare in the morning at breakfast. he had alzheimer's, which his level of intelligence was high enough to completely mask.
anyway, i digress. no, no offense taken at your suggestion. sometimes, people really are put into positions of responsibility and power and have to be the ones to solve these kinds of unique problems.
ok, metallurgy's answer is a good one, but let's think it through, by looking at the specification of various CPUs.
* Ingenic jz4760 has: 24-pin RGB/TTL, 2x USB2, 10/100 Ethernet, I2C, AC97/I2S, SD/MMC * TI's OMAPs typically have: 24-pin RGB/TTL, USB2, 10/100 Ethernet, I2C, I2S, HDMI, SD/MMC * Samsung's S5Pxxxx series typically have: 24-pin RGB/TTL, 2x USB2, 10/100 Ethernet, SATA, I2C, I2S, HDMI, SD/MMC and MIPI. the more advanced ones have PCIe. * The A10 has: 24-pin RGB/TTL, 3x USB2, 10/100 Ethernet, I2C, I2S, HDMI, 2x LVDS, SD/MMC, SATA
and so on, and so forth. in other words, these SoCs typically *don't even have* PCIe on-board: it's only the top-end ones that have it. therefore, it would be necessary to actually implement PCIe through some sort of memory-addressed PHY chip (if you can even find one), or to use a USB-to-PCIe bridge PHY chip (yes i actually found one. just the one).
so, the complexity and the cost would be increased, for no good reason, because the interfaces are already there! but also if you tried to save on that completely unnecessary cost, you would significantly reduce the speed (bandwidth).
in essence, then: these SoCs as a general rule already *have* USB, Sata, ethernet, HDMI, VGA etc. built-in, and to ignore those would be rather.... silly!
as metallurge points out: by contrast in the x86 world (and this relates to memory bandwidth more than anything), the architecture is wildly different. the anticipated communications bandwidth is VASTLY greater, mostly due to Graphics Cards (PCIe x 16 for goodness sake!) but also PCs typically have like 8x USBs, 2x or even 4x SATAs, at least 2x IDEs and many many more. all of that has to go out via a memory bus of some kind so it's no wonder that these x86 systems consume such vast amounts of power.
so yes: not only would the cost be greatly increased, but also the power consumption would be increased well beyond the 3.5W passive thermal limit we're setting for these CPU Cards. we are doing an 8mm variant with a 10W limit, especially for things like x86 AMD Fusion chipsets, and Intel's latest 32nm offerings, but we'll get to that in good time.
My thinking was that some things could be offloaded to the host device through expansion card slots. Perhaps the use of mini-pci cards or what have you for wifi. Perhaps extra RAM could be added as well without touching the EOMA-68 card.
yeah.... the problem is that there's very little space. the thickness of Mini-PCIe and Mini-PCI cards is typically around 5mm; that's actually the thickness of the PCMCIA Cards themselves. there just really isn't room. likewise for SO-DIMMs. but there's an extra problem with SO-DIMMs: they typically have a 64-bit-wide data bus, whereas most of the mid-end ARM SoCs we're dealing with only have 32-bit. you simply can't wire the two up without either putting in a funnel chip or wasting half the RAM on the SO-DIMM. so it would be necessary to create a custom SO-DIMM, and to be honest, what's the point?
so yeah we've been over these things: unfortunately when you get to the details, most of them don't work, or they are cost-prohibitive. i'm hoping someone will come up with some new ideas, because we're fresh out!:)
Which has me wondering while Intel and AMD aren't doing their own Manhattan project to produce their own full-featured SoCs rather than the more powerful but less integrated APUs.
others have covered the other points, but i wanted to share my insights on this one. i've mentioned before that i believe the x86 architecture has painted itself into a corner, from an instruction-level perspective more than anything else. it takes some going-over, please bear with me.
to explain: the x86 instruction set was designed to be exceptionally memory-efficient, at a time when the price of memory was at a premium. opcode "extensions" were added to keep up-to-date, but even there, the ethos of keeping the instructions very very compact meant that you need much much less memory. inner loops and 2nd-level loops could easily fit into a smaller 1st-level cache, etc. etc.
contrast this with the "RISC" approach, which was to be somewhat... wasteful of memory bandwidth, by having 32-bit (or so) instructions that are very very easy to decode. ARM then actually had to add "compression" on top of that (thumb) but that's an aside - the point is that by contrast, RISC CPUs are much much simpler but typically require considerably more memory to execute the exact same program. 1st-level and 2nd-level caches have to be double the size of an x86 CPU in order to have the same level of performance, etc. etc.
but, here's the thing: whilst x86 instructions are more "compact", the decode phase has to be run at a *much* faster clock-rate than an equivalent RISC CPU. hence the reason why there's that dual-core ARM Cortex A9 500mhz web browser demo online (youtube) from ARM, where it easily keeps up with a 1.6ghz Intel Atom.... you're probably starting to get the picture now: the x86 architecture has to run at over *twice* the speed of a RISC CPU to achieve the same result (which means a 4x increase in power consumption - power operates as a square law with execution speed), or it has to have ultra-complex "parallel decode and execute" engines, farming the decoded instructions to a more simpler RISC core, internally, but again *still* requiring a massive increase in power consumption.
you see the problem? x86 is in serious difficulties. to compete with RISC cores, it has to run in at least *half* the geometry of a RISC CPU in order to be faster and also as power-competitive... but... but... you can't stop RISC CPUs from having access to the same geometry as x86 CPUs!... now do you appreciate why intel is focussing so hard on staying one geometry step ahead of everyone else? why they're probably already working on developing the geometry below the 22nm mark whilst *simultaneously* pushing to put their latest CPUs into 22nm, when everyone else is struggling to get hold of 28nm through GlobalFoundries and TSMC? it's because they *have* to. AMD sold off GlobalFoundries, and they're really, really struggling as a result.
think about it: if you put an ARM Cortex A9 CPU Core into 28nm, it ROCKS! 1.5ghz and above is easy. the A15 CPU Core has a Harvard Architecture with performance a great deal above the Cortex A9, and i've heard of a company that TI bought recently who have a 2ghz Quad-Core Cortex A15 monster, it's fricking awesome, and uses only 10 watts!
Intel and AMD *cannot* compete with this - they just... can't. so, yeah: i've been trying to point this out to AMD via some friends i know, for several years: they don't want to hear it. Intel are bright enough to work it out for themselves, and they have the cash reserves to keep ahead on the geometries so they'll do ok. for now. so stupid of them to sell the PXA design *but*, remember - they *didn't* sell Marvell their $100k "unlimited" ARM license that they got from ARM during a bad patch of ARM's financial history....:)
So...it's a CPU that uses an actual real standard for connecting to the rest of the motherboard/system?
yeah. actually, several "lowest-common-denominator" standards, just placed onto nothing more complex than an existing legacy (but still manufactured) standard.
PCMCIA is still manufactured in mass-volume, but not as PCMCIA. instead, it's been re-used by the Satellite TV Industry for decrypt purposes. that makes it perfect: the risk of people misunderstanding EOMA-68 as being an *actual* PCMCIA card (when it isn't) is reduced, but the cost of manufacturing the EOMA-68 cards isn't sky-high due to having to make an entirely new connector (or use one of the less common $12 ones).
EOMA-68 itself is made up of well-established proven standards that have down-level negotiation built-in, as well as multi-peripheral support (ok, except for 24-pin RGB/TTL that is!). SATA, USB2, I2C and Ethernet: they're all multi-bus standards that have been around for at least a decade. with the exception of SATA, it's actually quite hard to find an embedded SoC that *doesn't* have all the interfaces of EOMA-68, and even there you can put on USB2-to-Ethernet or USB2-to-SATA. ironically, though, the cost of those ICs actually pushes the BOM up by an extra $5, making it completely pointless to consider using a lower-cost SoC that *doesn't* have Ethernet and SATA built-in. many people asked us to use Allwinner's $5 A13 CPU for an EOMA-68 CPU Card: when i pointed out that it would need an extra $5 of components, taking it *above* the mass-volume price of the Allwinner A10 CPU they went... "oh. yeah. duh. go figure:)"
Wow. Standards for freedom for end users, something the megacorps purposefully forget about. What a concept.
yeah. you get it. that's really encouraging to hear. take it one step further though: think the implications through. cost savings for the users. increased competition amongst CPU Card suppliers bringing prices down. ability of end-users to extend the lifetime of a product until one component literally falls apart... and them being able to just go down to the hypermarket and pick up a replacement screen, replacement battery pack or replacement CPU Card off-the-shelf, 1 or even 10 years from now, and it's *still* backwards-compatible.... now we just need to be able to convince companies like Three.co.uk, Best Buy, John Lewis, Walmart etc. and to come up with a story for them that will convince them to buy 100k+ units a month:)
ah. no. this page explains the different approaches. it's definitely *not* a factory-installable module. the key is in giving the *users* the freedom to safely upgrade their own computing appliances at will. none of those computer-on-module factory-installable modules can be said to achieve that goal. imagine your grandma trying to insert an SO-DIMM form-factor computer-on-module after keeping it her handbag, wrapped in her best polyester scarf for a week. what do you think the chances of success are? by contrast: now take the standard PCMCIA form-factor. chances of success just went up by an infinite percentage, didn't they?
you can see from that that there are *eleven* variants on 5 main OSes available. openembedded covers a ton of options just on its own. debian, ubuntu, redsleeve (a fedora-ARM port), puppy linux, android 3, android 4.
the similarity between the Mele A1000 and the A10 EOMA-68 CPU card is very strong: it's the reason why the A1000 was picked. that and the fact that it was affordable for everyone who wanted to help out:)
24-pin RGB/TTL you can drop down even to as low as 15 pin by ignoring the higher-res bits; you can reduce the clock-rate to run a 320x240 LCD or you can ramp it up to run 2048x2048 @ 30fps in full colour.
So they design a new modular computing interface for phones, tablets and computers, but it can't even support the current benchmark iPad 2 (2048×1536 at 60Hz, refresh rate not confirmed)?
yes, that's right. i'm looking forward to our clients being able to clean up in the much more lucrative and much larger Chinese market for lower-to-mid-end "good enough" products, from which we, as Europeans, in our market that is under 1/10th the size of the China internal market, can benefit from vastly-reduced hardware costs for "good enough" computing products.
chasing after apple is known to be futile. however if we can get the retail price down, for any given product, to under $95 (or £95) then that's "throw-away" money. it's "christmas present" money. a friend of mine bought 2 of those little Skytone Alpha 400s for her daughters about 4 years ago. she _regretted_ it, but the thought was there, and two figures is that watershed financial mark that even someone who is struggling to pay the mortgage can seriously consider buying for their kids.... i don't see apple's top-end products being under $99 any time soon, do you? it's a completely different approach. let apple and microsoft forge ahead, tumbling down the prices of hardware for us. the only thing we have to do: make damn sure that the products made are a leeetle bit better than the Skytone Alpha 400:) it was a break-through product (375mhz MIPS clone) but... times have moved on.
look at line 95 down to 113: you'll see that that's an MII interface. MII is only 10/100 (GMII and RGMII are 10/100/1000). another way to tell is from the use of the RTL8201CP (link to the datasheet from the pcb page) which is a 10/100 PHY chip. however the EOMA-68 interface we've specified as being up/down negotiable from 10 to 100 to 1000 so that yes, future CPU Cards can be Gigabit Ethernet. that's mainly so that people can consider making ultra-low-power server farms out of commodity off-the-shelf mass-volume CPU Cards in the future. which i'm really looking forward to.
Yeah I've been following this for a while as well. I was originally confused by the purpose of the PCMCIA card, but it eventually came through in my mind the idea that the PCMCIA card shaped object is just a REALLY EASILY replaceable motherboard that plugs in to a host device. Granted it's not a PCMCIA card, and it's not called a PCMCIA card.
... now translate that across a language barrier (chinese) and you start to appreciate how effing hard it's been for factories and even our clients to "get it":)
I like the premise. Buy a barebones laptop shell, plug in the EOMA-68 card device, and boot up. Or plug it into some other type of form factor. Inside of a TV. Inside a media player device. Inside a tablet. So many options. This could be big.
i know, i know! we want it to be. it's got a lot more potential than e.g. the q-seven standard. q-seven is really targetted at x86 and ultra-high-end ARM SoCs: the standard is some 250 pins and requires 4-lane PCI-express, 8x USB2, HDMI, Dual-channel LVDS, SATA-III and many more. that's not... mass-volume: it's too complicated. it's more a modular version of Nano ITX PCs. so we feel that a 68-pin credit-card-sized computer only 5mm high is more... end-user orientated.
Assuming this uses the Allwinner A10 chip, What is the status of decent hardware video decoding support?
*sigh* you have to use libcedarx.a which isn't ideal. there's some people who have done a limaproject-style "wrapper" around libcedarx, with a view to calling the available functions and monitoring what they do, then documenting exactly what it does. i'd *like* to approach allwinner and ask them for the source code to libcedarx but i need a financial opportunity to do so (i.e. "if you don't give us the source code, we can't properly fulfil this order for $NNm of business per month, sorry.").
Frankly the fact that they put gigabit ethernet on board is pretty awesome. That's not something that comes with the SoC.
ah, it's worth pointing out that whilst the EOMA-68 standard allows up/down-level negotiation of 10, 100 or 1000 ethernet, the Allwinner A10 CPU *only* has 10/100. the 4 extra 1000 pins are *unused*. but i put them there for future CPUs.
If you did put it in a device shaped like a laptop, would you be able to add more ram, upgrade the wifi card, etc, like a normal laptop or are you stuck with what's on board? Not sure how the card deals with expandability.
you're stuck with what's on-board. sorry: these CPU Cards are too small to fit in e.g. an SO-DIMM or a NAND Flash "upgrade" module. it *might* be possible at some point to fit in a tiny tiny SATA-based SSD, but don't count on that happening even within 2 years. we figured that just being able to upgrade the entire CPU Card and sell the old one on ebay, donate it to charity, re-use it in a router or as a home server or something, would be attractive enough. it's throwing away the *entire* hardware just because one part of it is either broken or out-of-date, we feel that really pisses people off, so are doing at least something about that.
Still, if this catches on, maybe RMS will finally be able to move up from his yeeloong lemote
yeehawwww:) yeah, finally. i'd like to get RMS on-board with the A10 EOMA-68 CPU Card but there's one small bug-bear: the libcedarx proprietary video library. everything else at least has semi-useable working software (libre) replacements. Henrik managed to reverse-engineer the 1st stage bootloader: it's a 15k boot-up sequence which initialises the DDR3 RAM timings amongst other things. i've also deliberately designed the laptops to use WIFI modules (USB-based MiniPCIe) that require no non-free firmware (e.g. using the ATH9K chipset. you can find them easily on ebay and amazon)
but yes: if not this 1st CPU card then a subsequen
I've been here for a long while, and my brain has yet been melted
List them here, so at least you'll provide us with melt-proof brains a trip to the search engines
Thanks in advance !!
:) ok - that first story, the one on itwire, explains what the heck happened and why i started on this path at all. it was a GPL-violating laptop that, embarrassingly, i naively encouraged 20 people to buy the very first samples from a little china factory called "Chitech". i had no idea that the factory hadn't even been *supplied* with the source code, and assumed that they would supply it. when they wouldn't (because they couldn't) in order not to let down all the people i'd encouraged to buy the laptops i had to go into overdrive spending about a month working with frans pop, buy a hand-held oscilloscope and get out the soldering iron in order to reverse-engineer the hardware and create an alternative S3C6410 2.6.24 kernel and a debian installer for the device. at the same time i also began a GPL violations escalation which so unnerved the girls at the factory that they ceased working with the ODM who supplied the GPL-violating design. not entirely the result i was looking for, but hey.
anyway i'd been through this reverse-engineering saga before in 2004 with a bunch of HTC wince smartphones (i used to own 7 HTC smartphones!), so it wasn't as hard this time, but it sank in that this was an absolutely ridiculous way to go about things, and i decided to try to find people to work with to actually create the hardware *itself*. i then looked at modules (like the ones used in the GPL-violating laptop) and, on learning how expensive they were (usually $99-$150) decided there was no way this could succeed using modules.
i spoke about this to my friend and mentor and, slowly we morphed the idea into a mass-volume product, evaluating dozens of possible connectors for re-use, and patented the concept. for the first CPU card, we settled on PCMCIA, as it turned out to be perfect for re-use. also: it turns out that the client whom we've been advising has just taken on the automated assembly of some 20 million 3G PCMCIA modems for one of their customers. this was highly successful for them: they earned an *enormous* sum of money, and they gained the skill, equipment and confidence to make PCMCIA-card-sized devices.... just as we come along with a PCMCIA-sized computer and they're *also* looking to solve the problem of their unprofitable laptop business!... talk about jammy, or what?:)
anyway, back to the story: we started looking for SoC vendors willing to work with us, even though we had no cash, and started selling the advantages of the story and the opportunity to help our very large mass-volume client and for people to make large wads of cash some time in the future, instead. we had this mad idea of the EOMA-68 CPU Card becoming a de-facto standard which SoC vendors could create as their first BSP, on the basis that it takes all the hard work out of getting any given CPU *literally* straight into a mass-production environment with no additional changes, and happens to be a good format as an engineering board (similar to the origen, imx53qsb, pandaboard etc.)
the funny thing is that over the past 2 years we've learned that it's actually *not* a good idea to encourage anyone to expect an up-front cash payment for "work done": it sends completely the wrong message. for example, we approached over a hundred factories around Shenzen, and asked them if they wanted to convert their products to EOMA-68. they didn't understand. they asked "how many our tablet you want buy?" quite a lot. on average it took about 20 messages to get across to them that we wanted to partner with them. we help improve their products, we supply software services at zero cost and introduce them to our clients on a commission-basis, if they modify the products to our hardware spec without charging us. win-win
I'll say. I've never even heard of this project until now (blame my ignorant remark on Slashdot not leading with even a little bit of backstory, as usual.)
sorry! my fault. i wrote the original submission. it's been a loooong road. i only just noticed that i'd said "schematics" rather than "board layout", thanks (sincerely) to someone's comments here. i kinda assumed that people had been following. and ironically got criticised for putting in too many links in the submission, already. imagine how many slashdotters heads would have melted if i'd done all their work for them by putting in some extra backstory links?:)
Slashdot Mirror
Time to get WebOS running, ten minutes
Time to get OpenEmbedded build working, ten weeks
amount of time taken asking questions: 0 seconds. ability read and follow instructions: 0%. ability to complain: 100%. ability to file bugreport or contact forum or mailing lists requesting detailed instructions: 0%.
_come_ on, dude, you know the drill. if you can't get something working, *ask the developers*. give them detailed reports, help them diagnose the problem with the build instructions, so that they can be improved. over time, things get fixed, yeah?
what would you have the developers do, huh? if you understand what openembedded's "bitbake" command is really about, and understand how powerful it is, you wouldn't be complaining, you'd be somewhere in awe or possibly shock. openembedded has a bang-per-buck ratio that's wayyy above anything else available from the free software community. gentoo's portage, buildroot, debian's build system - they're all child's toys by comparison.
tell me if you know of any other cross-build system that, in order to correctly configure a package and cross-compile it, fires up a *native* gcc compiler and runs the autoconf configure script in a qemu command-line virtual environment. now that's just so fucking smart - it solves *all* the problems that all the other "autoconf cache" broken workarounds just can't get right.
the people who came up with openembedded are just... unbelievably smart people. they know that they don't have a lot of resources, so they come up with solutions that make up for it, and do the work in an automated fashion. they've been at this for over 10 years, so cut them some slack, ok?
having read all of the asimov books, including those written under commission by the Asimov Estate, i'm a bit concerned about this obsession with the famous "3 Laws of Robotics". later books came up with the "New Law" Robots, and several books covered a character called "Caliban", who was a robotic experimental "No Law" Robot that was framed for murder, escaped, and through naive, direct and untainted access to the world on which it was created, came up with its own ethics - its own "Laws", in pretty much exactly the same way that any intelligent human would.
my concern therefore stems from Asimov's own concerns, that the 3 Laws of Robotics resulted in a "coddled society". the "Giskardian" Robots had a Zeroth Law imprinted on them, via a Robot named "Giskard" who was accidentally one of the first telepathic robots, and possessed the ability to telepathically imprint thought patterns onto other beings (including other robots). R. Daneel, a humaniform robot, was the first to be so imprinted, and the implication from other books is that R. Daneel lived about 30,000 years and saw through - engineered and directed - the *entire* Foundation. the scope of Asimov's work is just... breathtaking when you read all the books.
the Zeroth Law Robots (Giskardians) interfered with humanity's evolution, for their own good; the 3 Law Robots (Calvanists) attempted to serve individual humans as best they could within the rigid confines of their programming. The key here is that both groups *interfered* with human development, as a direct result of their programming.
so the point is: i don't believe that it's a good idea to start advocating the 3 Laws as the absolute be-all and end-all answer as to how to shape and direct the creation of robotic intelligence. Asimov's own stories tell us a dozen or more ways in which the 3 Laws can go horribly wrong. i think we can decide for ourselves how best to create intelligent robots, thank you.
yeah. in an effort to throw trackers off the scent, the criminal mastermind selected "Arabic" as the language and "Cyrillic" for the keyboard. now the DHS and the Secret Service's heads have exploded in their efforts to understand why their terrorist suspect would appear to be so intelligent as to understand two foreign languages but would be so stupid as to format the wrong drive.
Wait, so the ARM Cortex A8 architecture is completely open while the Raspberry Pi's ARM11 architecture isn't? I'm not sure I follow...
Otherwise, this project looks very interesting!
ah sorry, you've misunderstood. SoCs are far more than just the CPU Architecture that's used to power them. if you look at pictures of silicon layouts, you'll see that the actual CPU part is only about 1% of the whole SoC. a whopping 10% is dedicated to the I/O pads, to get enough power to push the lines from 0 to 1 and vice-versa at the kinds of speeds people need. 20% or more is typically 1st level cache. peripherals is about 5% of the silicon area, and routing (buses which can sometimes be 512 bits wide) consumes vast areas.
also: if you look at the functional block diagrams of SoCs, you'll see that the actual CPU, usually in the centre, takes up something like 5% of the picture; the centre is surrounded by dozens of peripherals.
in other words, the actual CPU - ARM11 or Cortex A8, it doesn't really matter - is actually very insignificant. after all, the only thing it does is run general-purpose instructions. it's what that CPU is surrounded by - within that black box - that makes up the whole story.
in the case of the broadcom chip, the GPU is entirely proprietary. it's utterly, utterly secret. absolutely no details are provided about its operation, whatsoever. yes, sure, it has an opengl interface, but we do not know if it does more than that. it cannot be trusted. broadcom cannot be trusted. for all we know, it is storing information on the use of the chip so that if broadcom gain access to it and run a special sequence of commands, it tells them exactly what the chip has been used for. we just don't know.
the short version is: you're confusing an architecture with a system that *uses* that architecture as one of its components. just because that one component happens to be open does not mean that the details of the entire system are also open. in the case of the broadcom chip, we know for a fact that it is definitely NOT open, and that's what's pissing people off.
there are quite a lot of other points made in the original post - mention of patents, mention of cost etc etc - so it is quite easy to miss the key words "black box". focussing on the patents themselves in isolation is missing the point. it's *NOT* about the patents. it's about the fact that the device is a "black box".
so it depends on whether you consider hypocrisy to be important or not. many people do not. what broadcom is really saying is "we support education and learning using our products because it's a good wheeze that makes us money and makes us look good at the same time. but you're not permitted to learn about this, this or this feature: we're keeping that entirely secret. if you want the source code, you can fuck off".
the CPU being used has a rather unique design: the GPU boots up the CPU. the fact that the boot-up sequence is critically dependent on a proprietary blob to which no-one is given access REALLY pisses people off. privacy concerns, education hypocrisy: the works.
that's what we're doing with the http://rhombus-tech.net/ project. the scope of the project has the goals of the raspberrypi foundation as a subset; CPUs that we are actively pursuing have to have full GPL compliance, and are as open as possible / practical. where binary blobs exist, reverse-engineered alternatives are encouraged to be created. the first CPU Card is based on the Allwinner A10 (ARM Cortex A8, 1ghz, overclockable to 1.5ghz). the binary startup blob which is essential to set the DDR3 RAM timings before continuing with the 2nd phase of the boot process was reverse-engineered a few months ago; the MALI GPU has the limadriver project on the case; efforts are underway to investigate the proprietary video hardware encode/decode engine. we were given full access to the GPL kernel and u-boot sources within 48 hours of asking (even though we did not have a GPL compliance request outstanding).
answering your question, archiebunker: designing something better is a bit harder than you might imagine. full access to technical datasheets is often denied: you are literally at the mercy of the SoC vendor and if they don't like the way you dress, or smell, or if you're not one of their pally-pal pals you can flat-out forget gaining access to the documentation. one of the key reasons is that they simply don't know if you have the expertise, or if you can be trusted not to pass on information to their competitors. so, if it turns out that you don't have the expertise, and you have to come to them with questions, you just cost them money. if you leak information to their competitors, you REALLY just cost them money - serious money.
so what we're doing with the EOMA-68 initiative is to make the hard part - the CPU+DDR3+NAND - be "just a mass-produced component" that you can literally buy off-the-shelf in a retail store. if it comes in a case, you get access to the EOMA-68 interfaces and whatever else the CPU Card has on the user-facing front edge; if you buy it without the case, you also get access to the internal jumpers and additional connectors, for educational and R&D purposes as well as factory-install purposes.
we're getting there. it's been a long haul, and we will not stop. the team behind the initiative will be sticking with this for the next decade, keeping it constantly up-to-date and ensuring that new CPU Cards are always available.
here's the previous article about it - actually it was the PCB layout that was completed - the schematics were completed 2 months ago:
http://hardware.slashdot.org/story/12/09/07/2322207/rhombus-tech-a10-eoma-68-cpu-card-schematics-completed
I'd like to see a well-founded analysis of the differences of Atom and ARM, but superficial statements like "RISC is bad" don't cut it.
i've covered this a couple of times on slashdot: simply put it's down to the differences in execution speed vs the storage size of those instructions. slightly interfering with that is of course the sizes of the L1 and L2 caches, but that's another story.
in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
now, as we well know, power consumption is a square law of the clock rate. so in a rough comparison, in the same geometry (e.g. 45nm), that 1.6ghz CPU is going to be roughly TEN times more power consumption than that dual-core ARM Cortex A9. e.g. that 500mhz dual-core Cortex A9 is going to be about 0.5 watts (roughly true) and the 1.6ghz Intel Atom is going to be about 5 watts (roughly true).
what that means is that x86 is basicallly onto a losing game.... period. the only way to "win" is for Intel and AMD to have access to geometries that are at least 2x better than anything else available in the world. each new geometry that comes out is not going to *stay* 2x better for very long. when everyone has access to 45nm, intel and AMD have to have access to 22nm or better... *at the same time*. not "in 6-12 months time", but *at the same time*. when everyone else has access to 28nm, intel and AMD have to have access to 14nm or better.
intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Sorry, I have an x86/amd64 + DEC alpha historical bias, and don't really know a lot about ARM.
As a user, having the "southbridge" stuff integrated onto the CPU card means that you're essentially getting a whole new motherboard when you replace this CPU card. I always view a whole new motherboard as a whole new set of problems, in terms of potentially buggy hardware and drivers.
yes. absolutely. you've put your finger on the problem. i've mentioned this before, and... hang on, i think i even wrote a message to linus torvalds but of course, he's far too busy to read it :) 1sec let me see if i can find it.... hard to find hints, try this http://lkcl.net/linux/eoma.initiative.txt but also go (briefly!) over some of the others: http://lkcl.net/linux
the point is that each ARM processor is *wildly* different from all other ARM processors. linus doesn't understand this. he was at a meeting of all the arch maintainers and said "over half of you are from the ARM arch. go away! get yourselves sorted out!" and what he doesn't understand is that that's an impossible task. not even "device tree" will help solve it.
because all these ARM (and MIPS) processors are so heavily-integrated, there can NEVER BE a "common BIOS", and the level of commonality between each of the processors is so small that it forces the linux kernel to *become* the BIOS, effectively. i actually recommended at one point that the linux kernel be split down into separate projects: core, architecture support and device drivers. and i do _mean_ separate projects, each with their own separate source tree and maintainers.
then, not only is there virtually no common code between each of the processors (hundreds of them... and increasing) but then, precisely because of this total lack of commonality, and precisely because of the practice of "integrating" the CPU onto the motherboard, each device that *uses* one of these CPUs is UTTERLY UNIQUE.
let that sink in for a second.
every single piece of hardware which has an ARM or MIPS processor has UTTERLY UNIQUE code which *HARD-CODES* the ENTIRE device driver layout.
no wonder they're pushing this thing called "device tree" so hard, as it's believed that it will solve the problem: it won't. all it will do is move the problem out of *some* of the linux kernel source code, and will move the problem into the device-tree specification files, whilst also at the same time complicating the development of the device drivers themselves. ... but it doesn't end there. whereas in the x86 world, there's a BIOS which sorts out the boot process, there's... nothing in the ARM or MIPS world. so someone decided it would be a good idea, instead of using kexec, to create "u-boot". u-boot is a bastardisation of libc and bits of the linux kernel, combined into one application, allowing you to write very basic c applications, enough to initialise the low-level hardware and give you a few options. the problem is: it pulls in "bits of the linux kernel", in order to start up the hardware. can you spell "code duplication" and "maintenance nightmare?".
so this is one of the real reasons why we've come up with the EOMA initiative: to solve not only the GPL violations problem but also to help reduce the "device-driver nightmare" to manageable levels. think about it: rather than it being a "N CPUs" *times* "M hardware products", by splitting the products into modules along a series of "Bus-level" interfaces (SATA, USB, Eth, I2C), the linux kernel source code to support EOMA can be a "N CPUs" *plus* "M hardware products" *plus* a little bit of library overhead.
you see how powerful that is? we recognise that x86 is much, much easier to develop linux kernel support for, mostly because of common BIOS support but more because of the common dynamic "Buses" like PCI, PCIe, USB2, Firewire etc. all of which provide a clean bre
Serious question. Why would vendors support such an approach?
we have one vendor who *is* fully behind it. it took them a long time, a whiteboard and a lot of hand-waving but they got it. it was an amazing meeting, after 2 years of them not getting it, where they suddenly got excited and went, "hey! we have an all-in-one PC product: we could... we could... convert that to a TV or upgrade it by just changing the CPU Card!" and it was a eureka moment - such a relief :)
but the key for them is that they are an assembly company rather than a manufacturing company. a whopping half a MILLION square metres factory space screwdriver / assembly company. the modularity of the approach we've come up is absolutely perfect for them. other companies supply the EOMA-68 PCBs (a million at a time); they put them into the cases. other companies supply them with the parts needed for a laptop (a million at a time); they put them together.
one absolutely jammy coincidence for us is that they'd *just* been asked to assemble 20 million+ PCMCIA 3G modems for a customer of theirs. note: PCMCIA modems. exactly the same size and form-factor and even exactly the same components (PCMCIA connector) as the EOMA-68 CPU Card.
the problem for them right now is that their "assembly" approach, combined with the well-known *insanely* low margins in the x86 laptop business, leaves them completely unprofitable. all their suppliers of the parts make the margins; they don't. this is the situation that has to change, and we're privileged to be able to offer them a solution that they've accepted.
ultimately, i see this approach empowering smaller 3rd party companies to be able to re-enter the markets that they've been squeezed out of by the ever-decreasing margins of the PC business. the hard part, technically is the CPU Card. the most expensive part is the casework. not exactly sure how to deal with that: 3D printers sort-of spring to mind... anyway, just a thought.
I am not familiar with UK laws at the time, but it seems unlikely this was the fastest way of dealing with the problem. It sounds nice when told that way, but one could just as easily state that a third party discovery request would be a known stalemate, yet it was chosen over going directly to the people in charge of regulating imports, drugs, and/or murder and let them deal with it.
In other words, a third party request from police or other Executive players would have likely been granted quickly.
NO. Anthony Pickford's strategy was the reason *WHY* it is now Law in the UK that 3rd Party Discovery Requests must be complied with. before this case, if a 3rd party was requested, during the discovery phase, to provide information, there was *no* reason why or law compelling the 3rd party to comply.
look him up. of 36 changes to UK Law of the past 50 years, a full *EIGHTEEN* of those changes are - were - down to my uncle. the intelligent, gifted, angry, intolerant and vindictive silly man. *sigh*. he was responsible for example for a change to the "Dangerous Dogs" Act. his neighbour's very expensive, very loving and very beautiful japanese dog was forced to be muzzled but it had breathing difficulties and would have died if it was forced to wear a restrictive device: he took the case all the way through to the House of Lords and got the law changed to be more reasonable and sane.
anyway: whilst it sounds nice to make a third party request to "the police or to other executive players", if you think that through for a minute you'll find that it's not as effective. the *police* weren't the ones with the import records, were they? these "executive players" weren't the ones with the import records, were they? no - that would have been *abdicating* responsibility for dealing with the problem, wouldn't it? and they would have had to "engage" those people, and risk *NOT* being able to get them interested, get through their bureaucratic minds that action needed to be taken FAST, to stop people from being killed, wouldn't they?
instead, they went directly for the people who actually had the information.
This sounds like one of those TV Tropes where the main character thinks they are the only person who can solve the problem
:) well, he did solve it. he was one of these very intelligent and very forceful people who got shit done, and, sadly, despised anyone who was either unintelligent or weak in his view. he was charming to speak with during the afternoon and evening, in a social context, but an absolute fucking nightmare in the morning at breakfast. he had alzheimer's, which his level of intelligence was high enough to completely mask.
anyway, i digress. no, no offense taken at your suggestion. sometimes, people really are put into positions of responsibility and power and have to be the ones to solve these kinds of unique problems.
ok, metallurgy's answer is a good one, but let's think it through, by looking at the specification of various CPUs.
* Ingenic jz4760 has: 24-pin RGB/TTL, 2x USB2, 10/100 Ethernet, I2C, AC97/I2S, SD/MMC
* TI's OMAPs typically have: 24-pin RGB/TTL, USB2, 10/100 Ethernet, I2C, I2S, HDMI, SD/MMC
* Samsung's S5Pxxxx series typically have: 24-pin RGB/TTL, 2x USB2, 10/100 Ethernet, SATA, I2C, I2S, HDMI, SD/MMC and MIPI. the more advanced ones have PCIe.
* The A10 has: 24-pin RGB/TTL, 3x USB2, 10/100 Ethernet, I2C, I2S, HDMI, 2x LVDS, SD/MMC, SATA
and so on, and so forth. in other words, these SoCs typically *don't even have* PCIe on-board: it's only the top-end ones that have it. therefore, it would be necessary to actually implement PCIe through some sort of memory-addressed PHY chip (if you can even find one), or to use a USB-to-PCIe bridge PHY chip (yes i actually found one. just the one).
so, the complexity and the cost would be increased, for no good reason, because the interfaces are already there! but also if you tried to save on that completely unnecessary cost, you would significantly reduce the speed (bandwidth).
in essence, then: these SoCs as a general rule already *have* USB, Sata, ethernet, HDMI, VGA etc. built-in, and to ignore those would be rather.... silly!
as metallurge points out: by contrast in the x86 world (and this relates to memory bandwidth more than anything), the architecture is wildly different. the anticipated communications bandwidth is VASTLY greater, mostly due to Graphics Cards (PCIe x 16 for goodness sake!) but also PCs typically have like 8x USBs, 2x or even 4x SATAs, at least 2x IDEs and many many more. all of that has to go out via a memory bus of some kind so it's no wonder that these x86 systems consume such vast amounts of power.
so yes: not only would the cost be greatly increased, but also the power consumption would be increased well beyond the 3.5W passive thermal limit we're setting for these CPU Cards. we are doing an 8mm variant with a 10W limit, especially for things like x86 AMD Fusion chipsets, and Intel's latest 32nm offerings, but we'll get to that in good time.
My thinking was that some things could be offloaded to the host device through expansion card slots. Perhaps the use of mini-pci cards or what have you for wifi. Perhaps extra RAM could be added as well without touching the EOMA-68 card.
yeah.... the problem is that there's very little space. the thickness of Mini-PCIe and Mini-PCI cards is typically around 5mm; that's actually the thickness of the PCMCIA Cards themselves. there just really isn't room. likewise for SO-DIMMs. but there's an extra problem with SO-DIMMs: they typically have a 64-bit-wide data bus, whereas most of the mid-end ARM SoCs we're dealing with only have 32-bit. you simply can't wire the two up without either putting in a funnel chip or wasting half the RAM on the SO-DIMM. so it would be necessary to create a custom SO-DIMM, and to be honest, what's the point?
so yeah we've been over these things: unfortunately when you get to the details, most of them don't work, or they are cost-prohibitive. i'm hoping someone will come up with some new ideas, because we're fresh out! :)
oh bugger! thank you for the correction :)
Which has me wondering while Intel and AMD aren't doing their own Manhattan project to produce their own full-featured SoCs rather than the more powerful but less integrated APUs.
others have covered the other points, but i wanted to share my insights on this one. i've mentioned before that i believe the x86 architecture has painted itself into a corner, from an instruction-level perspective more than anything else. it takes some going-over, please bear with me.
to explain: the x86 instruction set was designed to be exceptionally memory-efficient, at a time when the price of memory was at a premium. opcode "extensions" were added to keep up-to-date, but even there, the ethos of keeping the instructions very very compact meant that you need much much less memory. inner loops and 2nd-level loops could easily fit into a smaller 1st-level cache, etc. etc.
contrast this with the "RISC" approach, which was to be somewhat... wasteful of memory bandwidth, by having 32-bit (or so) instructions that are very very easy to decode. ARM then actually had to add "compression" on top of that (thumb) but that's an aside - the point is that by contrast, RISC CPUs are much much simpler but typically require considerably more memory to execute the exact same program. 1st-level and 2nd-level caches have to be double the size of an x86 CPU in order to have the same level of performance, etc. etc.
but, here's the thing: whilst x86 instructions are more "compact", the decode phase has to be run at a *much* faster clock-rate than an equivalent RISC CPU. hence the reason why there's that dual-core ARM Cortex A9 500mhz web browser demo online (youtube) from ARM, where it easily keeps up with a 1.6ghz Intel Atom. ... you're probably starting to get the picture now: the x86 architecture has to run at over *twice* the speed of a RISC CPU to achieve the same result (which means a 4x increase in power consumption - power operates as a square law with execution speed), or it has to have ultra-complex "parallel decode and execute" engines, farming the decoded instructions to a more simpler RISC core, internally, but again *still* requiring a massive increase in power consumption.
you see the problem? x86 is in serious difficulties. to compete with RISC cores, it has to run in at least *half* the geometry of a RISC CPU in order to be faster and also as power-competitive... but... but... you can't stop RISC CPUs from having access to the same geometry as x86 CPUs! ... now do you appreciate why intel is focussing so hard on staying one geometry step ahead of everyone else? why they're probably already working on developing the geometry below the 22nm mark whilst *simultaneously* pushing to put their latest CPUs into 22nm, when everyone else is struggling to get hold of 28nm through GlobalFoundries and TSMC? it's because they *have* to. AMD sold off GlobalFoundries, and they're really, really struggling as a result.
think about it: if you put an ARM Cortex A9 CPU Core into 28nm, it ROCKS! 1.5ghz and above is easy. the A15 CPU Core has a Harvard Architecture with performance a great deal above the Cortex A9, and i've heard of a company that TI bought recently who have a 2ghz Quad-Core Cortex A15 monster, it's fricking awesome, and uses only 10 watts!
Intel and AMD *cannot* compete with this - they just... can't. so, yeah: i've been trying to point this out to AMD via some friends i know, for several years: they don't want to hear it. Intel are bright enough to work it out for themselves, and they have the cash reserves to keep ahead on the geometries so they'll do ok. for now. so stupid of them to sell the PXA design *but*, remember - they *didn't* sell Marvell their $100k "unlimited" ARM license that they got from ARM during a bad patch of ARM's financial history.... :)
So...it's a CPU that uses an actual real standard for connecting to the rest of the motherboard/system?
yeah. actually, several "lowest-common-denominator" standards, just placed onto nothing more complex than an existing legacy (but still manufactured) standard.
PCMCIA is still manufactured in mass-volume, but not as PCMCIA. instead, it's been re-used by the Satellite TV Industry for decrypt purposes. that makes it perfect: the risk of people misunderstanding EOMA-68 as being an *actual* PCMCIA card (when it isn't) is reduced, but the cost of manufacturing the EOMA-68 cards isn't sky-high due to having to make an entirely new connector (or use one of the less common $12 ones).
EOMA-68 itself is made up of well-established proven standards that have down-level negotiation built-in, as well as multi-peripheral support (ok, except for 24-pin RGB/TTL that is!). SATA, USB2, I2C and Ethernet: they're all multi-bus standards that have been around for at least a decade. with the exception of SATA, it's actually quite hard to find an embedded SoC that *doesn't* have all the interfaces of EOMA-68, and even there you can put on USB2-to-Ethernet or USB2-to-SATA. ironically, though, the cost of those ICs actually pushes the BOM up by an extra $5, making it completely pointless to consider using a lower-cost SoC that *doesn't* have Ethernet and SATA built-in. many people asked us to use Allwinner's $5 A13 CPU for an EOMA-68 CPU Card: when i pointed out that it would need an extra $5 of components, taking it *above* the mass-volume price of the Allwinner A10 CPU they went... "oh. yeah. duh. go figure :)"
Wow. Standards for freedom for end users, something the megacorps purposefully forget about. What a concept.
yeah. you get it. that's really encouraging to hear. take it one step further though: think the implications through. cost savings for the users. increased competition amongst CPU Card suppliers bringing prices down. ability of end-users to extend the lifetime of a product until one component literally falls apart... and them being able to just go down to the hypermarket and pick up a replacement screen, replacement battery pack or replacement CPU Card off-the-shelf, 1 or even 10 years from now, and it's *still* backwards-compatible. ... now we just need to be able to convince companies like Three.co.uk, Best Buy, John Lewis, Walmart etc. and to come up with a story for them that will convince them to buy 100k+ units a month :)
USB2 goes all the way from 11mbit/sec to 480mbit/sec.
Minor pedant point: it actually goes all the way down to the 1mbit/s USB 1 slow speed interface.
ah cool - thanks for the correction.
Having it completely OSS as well will also make life a happy dream with unicorns and rainbows and etc...
*lol*. hilarious. with extra virgins to go with the unicorns, and a pot of gold thrown in for free, arrr :)
ah. no. this page explains the different approaches. it's definitely *not* a factory-installable module. the key is in giving the *users* the freedom to safely upgrade their own computing appliances at will. none of those computer-on-module factory-installable modules can be said to achieve that goal. imagine your grandma trying to insert an SO-DIMM form-factor computer-on-module after keeping it her handbag, wrapped in her best polyester scarf for a week. what do you think the chances of success are? by contrast: now take the standard PCMCIA form-factor. chances of success just went up by an infinite percentage, didn't they?
http://elinux.org/Embedded_Open_Modular_Architecture
An ARM laptop? Dare I ask which OS?
any OS you like: that's the whole point. A10-based devices are "unbrickable" and are always upgradeable. there's a link here:
http://rhombus-tech.net/allwinner_a10/hacking_the_mele_a1000/
you can see from that that there are *eleven* variants on 5 main OSes available. openembedded covers a ton of options just on its own. debian, ubuntu, redsleeve (a fedora-ARM port), puppy linux, android 3, android 4.
the similarity between the Mele A1000 and the A10 EOMA-68 CPU card is very strong: it's the reason why the A1000 was picked. that and the fact that it was affordable for everyone who wanted to help out :)
24-pin RGB/TTL you can drop down even to as low as 15 pin by ignoring the higher-res bits; you can reduce the clock-rate to run a 320x240 LCD or you can ramp it up to run 2048x2048 @ 30fps in full colour.
So they design a new modular computing interface for phones, tablets and computers, but it can't even support the current benchmark iPad 2 (2048×1536 at 60Hz, refresh rate not confirmed)?
yes, that's right. i'm looking forward to our clients being able to clean up in the much more lucrative and much larger Chinese market for lower-to-mid-end "good enough" products, from which we, as Europeans, in our market that is under 1/10th the size of the China internal market, can benefit from vastly-reduced hardware costs for "good enough" computing products.
chasing after apple is known to be futile. however if we can get the retail price down, for any given product, to under $95 (or £95) then that's "throw-away" money. it's "christmas present" money. a friend of mine bought 2 of those little Skytone Alpha 400s for her daughters about 4 years ago. she _regretted_ it, but the thought was there, and two figures is that watershed financial mark that even someone who is struggling to pay the mortgage can seriously consider buying for their kids. ... i don't see apple's top-end products being under $99 any time soon, do you? it's a completely different approach. let apple and microsoft forge ahead, tumbling down the prices of hardware for us. the only thing we have to do: make damn sure that the products made are a leeetle bit better than the Skytone Alpha 400 :) it was a break-through product (375mhz MIPS clone) but... times have moved on.
http://en.wikipedia.org/wiki/Skytone_Alpha-400
Gigabit Ethernet goes through 10 to 100 to 1000.
Does the Allwinner A10 support Gigabit Ethernet? Or is it the EOMA-68 that allows for future boards with GbE?
the latter.
http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68#Table_of_EOMA-68_pinouts
http://git.rhombus-tech.net/?p=eoma.git;a=blob;f=pcb/allwinner_a10/library/allwinner.lib;h=cd435ae32f3049d7b6dcb524af0fcc6ec1a6b77d;hb=dfaa27a0ec6db9eaaa8abc74c68849caa64b721b#l95
http://rhombus-tech.net/allwinner_a10/pcb/
look at line 95 down to 113: you'll see that that's an MII interface. MII is only 10/100 (GMII and RGMII are 10/100/1000). another way to tell is from the use of the RTL8201CP (link to the datasheet from the pcb page) which is a 10/100 PHY chip. however the EOMA-68 interface we've specified as being up/down negotiable from 10 to 100 to 1000 so that yes, future CPU Cards can be Gigabit Ethernet. that's mainly so that people can consider making ultra-low-power server farms out of commodity off-the-shelf mass-volume CPU Cards in the future. which i'm really looking forward to.
Mali may currently be proprietary, but I'd say in 6 months to a year, that won't be the case anymore. Just my subjective feeling.
http://limaproject.org/
Yeah I've been following this for a while as well. I was originally confused by the purpose of the PCMCIA card, but it eventually came through in my mind the idea that the PCMCIA card shaped object is just a REALLY EASILY replaceable motherboard that plugs in to a host device. Granted it's not a PCMCIA card, and it's not called a PCMCIA card.
... now translate that across a language barrier (chinese) and you start to appreciate how effing hard it's been for factories and even our clients to "get it" :)
I like the premise. Buy a barebones laptop shell, plug in the EOMA-68 card device, and boot up. Or plug it into some other type of form factor. Inside of a TV. Inside a media player device. Inside a tablet. So many options. This could be big.
i know, i know! we want it to be. it's got a lot more potential than e.g. the q-seven standard. q-seven is really targetted at x86 and ultra-high-end ARM SoCs: the standard is some 250 pins and requires 4-lane PCI-express, 8x USB2, HDMI, Dual-channel LVDS, SATA-III and many more. that's not... mass-volume: it's too complicated. it's more a modular version of Nano ITX PCs. so we feel that a 68-pin credit-card-sized computer only 5mm high is more... end-user orientated.
Assuming this uses the Allwinner A10 chip, What is the status of decent hardware video decoding support?
*sigh* you have to use libcedarx.a which isn't ideal. there's some people who have done a limaproject-style "wrapper" around libcedarx, with a view to calling the available functions and monitoring what they do, then documenting exactly what it does. i'd *like* to approach allwinner and ask them for the source code to libcedarx but i need a financial opportunity to do so (i.e. "if you don't give us the source code, we can't properly fulfil this order for $NNm of business per month, sorry.").
Frankly the fact that they put gigabit ethernet on board is pretty awesome. That's not something that comes with the SoC.
ah, it's worth pointing out that whilst the EOMA-68 standard allows up/down-level negotiation of 10, 100 or 1000 ethernet, the Allwinner A10 CPU *only* has 10/100. the 4 extra 1000 pins are *unused*. but i put them there for future CPUs.
If you did put it in a device shaped like a laptop, would you be able to add more ram, upgrade the wifi card, etc, like a normal laptop or are you stuck with what's on board? Not sure how the card deals with expandability.
you're stuck with what's on-board. sorry: these CPU Cards are too small to fit in e.g. an SO-DIMM or a NAND Flash "upgrade" module. it *might* be possible at some point to fit in a tiny tiny SATA-based SSD, but don't count on that happening even within 2 years. we figured that just being able to upgrade the entire CPU Card and sell the old one on ebay, donate it to charity, re-use it in a router or as a home server or something, would be attractive enough. it's throwing away the *entire* hardware just because one part of it is either broken or out-of-date, we feel that really pisses people off, so are doing at least something about that.
Still, if this catches on, maybe RMS will finally be able to move up from his yeeloong lemote
yeehawwww :) yeah, finally. i'd like to get RMS on-board with the A10 EOMA-68 CPU Card but there's one small bug-bear: the libcedarx proprietary video library. everything else at least has semi-useable working software (libre) replacements. Henrik managed to reverse-engineer the 1st stage bootloader: it's a 15k boot-up sequence which initialises the DDR3 RAM timings amongst other things. i've also deliberately designed the laptops to use WIFI modules (USB-based MiniPCIe) that require no non-free firmware (e.g. using the ATH9K chipset. you can find them easily on ebay and amazon)
but yes: if not this 1st CPU card then a subsequen
Don't worry, just list them all out here
I've been here for a long while, and my brain has yet been melted
List them here, so at least you'll provide us with melt-proof brains a trip to the search engines
Thanks in advance !!
:) ok - that first story, the one on itwire, explains what the heck happened and why i started on this path at all. it was a GPL-violating laptop that, embarrassingly, i naively encouraged 20 people to buy the very first samples from a little china factory called "Chitech". i had no idea that the factory hadn't even been *supplied* with the source code, and assumed that they would supply it. when they wouldn't (because they couldn't) in order not to let down all the people i'd encouraged to buy the laptops i had to go into overdrive spending about a month working with frans pop, buy a hand-held oscilloscope and get out the soldering iron in order to reverse-engineer the hardware and create an alternative S3C6410 2.6.24 kernel and a debian installer for the device. at the same time i also began a GPL violations escalation which so unnerved the girls at the factory that they ceased working with the ODM who supplied the GPL-violating design. not entirely the result i was looking for, but hey.
anyway i'd been through this reverse-engineering saga before in 2004 with a bunch of HTC wince smartphones (i used to own 7 HTC smartphones!), so it wasn't as hard this time, but it sank in that this was an absolutely ridiculous way to go about things, and i decided to try to find people to work with to actually create the hardware *itself*. i then looked at modules (like the ones used in the GPL-violating laptop) and, on learning how expensive they were (usually $99-$150) decided there was no way this could succeed using modules.
i spoke about this to my friend and mentor and, slowly we morphed the idea into a mass-volume product, evaluating dozens of possible connectors for re-use, and patented the concept. for the first CPU card, we settled on PCMCIA, as it turned out to be perfect for re-use. also: it turns out that the client whom we've been advising has just taken on the automated assembly of some 20 million 3G PCMCIA modems for one of their customers. this was highly successful for them: they earned an *enormous* sum of money, and they gained the skill, equipment and confidence to make PCMCIA-card-sized devices.... just as we come along with a PCMCIA-sized computer and they're *also* looking to solve the problem of their unprofitable laptop business! ... talk about jammy, or what? :)
anyway, back to the story: we started looking for SoC vendors willing to work with us, even though we had no cash, and started selling the advantages of the story and the opportunity to help our very large mass-volume client and for people to make large wads of cash some time in the future, instead. we had this mad idea of the EOMA-68 CPU Card becoming a de-facto standard which SoC vendors could create as their first BSP, on the basis that it takes all the hard work out of getting any given CPU *literally* straight into a mass-production environment with no additional changes, and happens to be a good format as an engineering board (similar to the origen, imx53qsb, pandaboard etc.)
the funny thing is that over the past 2 years we've learned that it's actually *not* a good idea to encourage anyone to expect an up-front cash payment for "work done": it sends completely the wrong message. for example, we approached over a hundred factories around Shenzen, and asked them if they wanted to convert their products to EOMA-68. they didn't understand. they asked "how many our tablet you want buy?" quite a lot. on average it took about 20 messages to get across to them that we wanted to partner with them. we help improve their products, we supply software services at zero cost and introduce them to our clients on a commission-basis, if they modify the products to our hardware spec without charging us. win-win
be kind, please! he made a mistake - it's ok. i've made enough, god knows... :) that's how you make progress.
I'll say. I've never even heard of this project until now (blame my ignorant remark on Slashdot not leading with even a little bit of backstory, as usual.)
sorry! my fault. i wrote the original submission. it's been a loooong road. i only just noticed that i'd said "schematics" rather than "board layout", thanks (sincerely) to someone's comments here. i kinda assumed that people had been following. and ironically got criticised for putting in too many links in the submission, already. imagine how many slashdotters heads would have melted if i'd done all their work for them by putting in some extra backstory links? :)
anyway: there's a bit more about the background, here: http://www.itwire.com/opinion-and-analysis/open-sauce/52054-british-company-looks-to-create-cheap-open-platforms - pleaase for goodness sake ignore the mistaken reporting of a "$15" sale price.... but otherwise it's all good stuff.