Raspberry Pi interview: Eben Upton reveals all (Linux User)
It’s not entirely clear to me why the Beagleboard is so expensive. Somebody in that Beagleboard value chain has got to be making a pile of money – I mean, $175 for a Pandaboard or $100 for a Beagleboard? Somebody’s got to be amassing a pile of cash there, because that’s a $10 chip in that device. I don’t know why they’re so expensive. Raspberry Pi, in terms of multimedia, outperforms any other dev board in existence – which is nice. [...] In terms of general purpose computing, it’s got this 700MHz ARM11, and our benchmark shows it’s about 20 per cent slower than a Beagleboard for general purpose computing. But, you know, it’s a quarter of the price – somewhere between a sixth and a quarter of the price – so yeah, I expect that our first customers are going to be Beagleboard-type customers."
Posted Mar 6, 2012 2:33 UTC (Tue)
by Zizzle (guest, #67739)
[Link] (18 responses)
Farnell were talking about 700 hits a second on release day.
Mean while Ubuntu are saying ARMv6 is too hard and busy patting themselves on the back for Unity.
What do I know, maybe this is the right move, maybe Ubuntu will take the world by storm with their proprietary desktop for Android.
Posted Mar 6, 2012 3:25 UTC (Tue)
by allesfresser (guest, #216)
[Link]
Posted Mar 6, 2012 4:12 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (14 responses)
Canonical has made a rational business decision on how to expense resources for native build infrastructure to primarily target consumer device OEMs.This particular ARM arch is losing favor in commercial OEM device development.
Canonical has never promised to provide build hosts for all the arches that Debian supports. In fact from day one Canonical said very forthrightly that Ubuntu will be much more focused as to which arches it supports. So it should be expected that Debian will continue to have wider architecture coverage than Ubuntu.
This is not new behavior for Canonical. We have seen Canonical decide to shutter multiple arches in the past based on a lack of commercial interest. They did support sparc, ia64 and hppa for a period of time, and then subsequently dropped those arches.
And the reality is in the long term the multiarch concept being pushed forward inside Debian and Ubuntu now should make the problems with having to expense and maintain dedicated native build infrastructure for each arch moot. Multiarch baked into Debian and thus Ubuntu, will hopeful make it possible for the Ubuntu community to take over the responsibility of maintaining arches that are not of commercial interest to Canonical, without costing Canonical additional expense to provide the native builders. In fact the multiarch related changes to standardize cross-compiling support should help everybody. Right now we are sort of in a doughnut hole in the long term plan to make the ARM ecosystem maintainable until the multiarch cross-compiling changes are fully in place.
-jef
Posted Mar 6, 2012 7:26 UTC (Tue)
by dlang (guest, #313)
[Link] (10 responses)
I think that Canonical is really missing the boat on this one.
I see this as a 'get them early' opportunity for linux distros.
The Rasperry Pi boardsare a little less powerful than the android phones that they are currently targeting, but the raspberry pi boards are only going to get faster over time (like the phones), and the distro that the kids are comfortable hacking with on their own is the one that they will use on more powerful machines as they grow up and get jobs.
This is exactly how RedHat got to critical mass in the datacenter, and I hate to see any Linux distro abandon it.
At the same time, I can see why if they did not support the chipset in the current releases, that they would want to have the raspberry pi folks stop saying that they were running Ubuntu on them, that would just lead to false expectations and a big backlash at release time.
Posted Mar 6, 2012 7:55 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link]
The underlying problem here is that Canonical very deliberately setup the Ubuntu build system so that it was exceedingly difficult for the external Ubuntu community to replicate builders and integrate them into the blessed Ubuntu process which runs through launchpad. It is and always has been part of Canonical business strategy to control the builders as core infrastructure and to use that as leverage with OEMs to pay for engineering services.
External Ubuntu contributors simply do not have the ability to band together and supply the necessary builders for an arch that Canonical does not deem it a good business investment to maintain. This stands is contrast to how the Fedora contributors at Seneca were able to replicating Fedora's koji build system instead of waiting for Red Hat to do the heavy lifting to get the ball rolling before contributing hardware to the cause.
I can't stress this enough, Debian's decentralized build system and associated policies is key to the wide range of arch support Debian currently has. A system that predates Ubuntu. Canonical could have replicated that decentralized approach and chose not. Ubuntu continues to suffer from that very calculated choice to drastically recentralize.
Now, Debian's multiarch concept may provide an opportunity to give the external Ubuntu community a new way to step up and lead where Canonical does not see immediate business opportunity, but if and only if Canonical is willing to cede leadership and control.
-jef
Posted Mar 6, 2012 8:03 UTC (Tue)
by kragil (guest, #34373)
[Link] (4 responses)
Posted Mar 6, 2012 10:15 UTC (Tue)
by thisisme (guest, #83315)
[Link] (3 responses)
Posted Mar 6, 2012 13:38 UTC (Tue)
by kragil (guest, #34373)
[Link] (1 responses)
Posted Mar 7, 2012 4:05 UTC (Wed)
by thisisme (guest, #83315)
[Link]
Posted Mar 6, 2012 14:51 UTC (Tue)
by Cato (guest, #7643)
[Link]
Linux Mint LXDE would also be a good option, as it's Debian Testing based, but someone would have to do the work of ARMv6 support - http://blog.linuxmint.com/?p=1930 ... Probably easier to use Debian directly and port a few Linux Mint bits over if needed.
I agree that it's a strategic mistake for Canonical to miss out on such a huge grass roots movement that focuses on Linux hacking for kids.
Posted Mar 6, 2012 11:37 UTC (Tue)
by pboddie (guest, #50784)
[Link] (3 responses)
I'm not particularly impressed by some of Canonical's decision-making, but you can't really blame them for not wanting to support a sub-architecture that is effectively going away, at least in the space in which they operate. As for whether there will be faster Raspberry Pi boards, that remains to be seen. There's a surge of cheap solutions based on newer ARM designs coming out of China (it's worth keeping up with this page on this topic), already being put into relatively cheap mass-market products. That phenomenon isn't exactly going away. For once, I sympathise with Jono Bacon wearing his Canonical hat, though. From what I've read from members of the Raspberry Pi initiative and its more enthusiastic followers, there's a tendency to "trash-talk" other initiatives and organisations - the guy answers his own question about why you have to pay $150 for a "competing" (not complementary) board - and there seems to be a need to be seen as the solution to a problem it isn't clear that the initiative is currently adequately addressing, anyway. Already, it would appear that people are feeling let down by being sent off to Farnell - I imagine that most people's experience of that company is about being made all too aware that Farnell doesn't want their business - and although many people are probably just interested for the cheap kit, I fear that enough discontent will have been encouraged in the whole exercise, particularly by the culture around the initiative, that it may all come back down to Earth in an unpleasant fashion.
Posted Mar 6, 2012 12:31 UTC (Tue)
by misc (subscriber, #73730)
[Link] (2 responses)
People complain to distribution that the latest version of their favorite software is not in their os mainly because they know it exists and because they know that complaining could make it appear. If distribution did like Microsoft or Apple and announce it once everything is ready ( ie, skip the transparency bit of free software, and just speak once it is usable by end users of distribution ), users would surely be less demanding.
That's the same for the boards. Since the fundation have been communicating around it, giving more information than what people could expect from any company, they are mad because "OMG, I have to wait or I need to face real life problem". Mad because someone did the efforts to discuss with them, and because in the end, they forgot that production take time, that sometimes, people have to wait.
Posted Mar 6, 2012 13:35 UTC (Tue)
by pboddie (guest, #50784)
[Link] (1 responses)
Has it really been that open? I haven't been following all the discussions - every blog post is followed by hundreds of responses ranging from "blue sky" brainstorming to "Can you sign me up to the mailing list?" - but I've seen a degree of backtracking and various decisions being reversed, plus people offering advice being told to keep it to themselves (in quite an aggressive fashion in some cases; anyone complaining about the use and abuse of the Ubuntu Code of Conduct for stifling discussion should spend an hour or so on the Raspberry Pi forums, just to "recalibrate"). I follow various open hardware lists where production issues are openly discussed, not just announcements about whether the deadlines will be met. No-one is under any illusions about the readiness or availability of the products on those lists, nor are people mad or impatient at those leading those initiatives. In fact, everyone seems willing to learn from everyone else. If the disciplines of communications and marketing ever needed a case study to demonstrate their relevance, they might have found one here, however.
Posted Mar 6, 2012 16:55 UTC (Tue)
by misc (subscriber, #73730)
[Link]
And I agree that indeed, the same problem that plague Android bug tracker, cyanogen blog and others stuff targeted to some population, plague the blog of the fundation, IE there is too much feedback ( and not that useful :/ ).
Posted Mar 6, 2012 12:02 UTC (Tue)
by wookey (guest, #5501)
[Link] (2 responses)
Posted Mar 6, 2012 16:56 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
If you are correct, and I am wrong, then it'll be that much more difficult for the external Ubuntu community to spin up support for this specific arch based entirely on sweat equity without buy-in from Canonical to provider the additional infrastructure and tie it into launchpad. That would be very unfortunate. I'd rather wish you were wrong, but I guess I'm holding out too much hope for the new technical capabilities to work around the corporate/community conflict of interest dynamic.
-jef
Posted Mar 6, 2012 18:46 UTC (Tue)
by wookey (guest, #5501)
[Link]
wrt to distro support I'd say why not just use Debian on your Pi? No particular reason to use Ubuntu in this case. There is already a Debian image and it will no doubt become a supported platform.
Posted Mar 6, 2012 7:49 UTC (Tue)
by augustl (guest, #75060)
[Link] (1 responses)
Is it really proprietary? My understanding was that you need permission to distribute Ubuntu-branded commercial devices, other than that I haven't seen anything specific about licensing and availability of the code for Ubuntu for Android.
Posted Mar 6, 2012 9:10 UTC (Tue)
by gidoca (guest, #62438)
[Link]
Posted Mar 6, 2012 5:06 UTC (Tue)
by Imroy (guest, #62286)
[Link] (6 responses)
Also, Broadcom are subsidising the price of the RPi. I think TI also subsidises the Beagle/Panda boards, so maybe there's just a difference in how much each manufacturer subsidises their board(s).
As for performance, I want to see the benchmark results. The multi-issue super-scalar Cortex-A8 and A9 cores are reported to be able to perform 2.0 and 2.5 DMIPS/MHz, respectively. The aging ARM11 core only does about 1.0 DMIPS/MHz. So the claim that a 700 MHz ARM11 (~700 DMIPS) is only 20% slower than a 600 MHz Cortex-A8 (~1200 DMIPS) just doesn't "add up". Maybe something like a faster memory bus is helping it perform better on a certain benchmark.
Posted Mar 6, 2012 5:36 UTC (Tue)
by alison (subscriber, #63752)
[Link] (2 responses)
I strongly suspect that contrary to "making piles of money" on these products that T.I. has actively subsidized them, but I am not party to inside information.
Posted Mar 6, 2012 6:54 UTC (Tue)
by koenkooi (subscriber, #71861)
[Link]
Posted Mar 6, 2012 8:10 UTC (Tue)
by kragil (guest, #34373)
[Link]
Posted Mar 6, 2012 11:26 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Mar 7, 2012 16:51 UTC (Wed)
by juliank (guest, #45896)
[Link]
Posted Mar 7, 2012 5:41 UTC (Wed)
by geuder (subscriber, #62854)
[Link]
I would be satisfied with real user experience. If it is a desktop used for browsing, how fast does it feel.
> The multi-issue super-scalar Cortex-A8 and A9 cores are reported to be able to perform 2.0 and 2.5 DMIPS/MHz, respectively.
The problem with all the nice multi-ussue, super-scalar (and you don't mention multicore for the A9) is that it needs a suitable workload and excellent compiler support or even hand crafted assembler (e.g. NEON) to perform optimally. All the nice high tech does not help if it waits for the network or the mass memory. Unfortunatley it often enough even waits for its "own" cache. I have seen A8 running at less than 30% of its theoretical performance far more often than I would have liked.
> The aging ARM11 core only does about 1.0 DMIPS/MHz. So the claim that a 700 MHz ARM11 (~700 DMIPS) is only 20% slower than a 600 MHz Cortex-A8 (~1200 DMIPS) just doesn't "add up"
Well maybe the imbalance between a too fast CPU and a two slow everything else is just not as bad on the older systems. So I would definitely not rule out a smaller observed difference in performance than what the theoretical maximum figures tell.
Posted Mar 6, 2012 7:52 UTC (Tue)
by nhippi (subscriber, #34640)
[Link]
http://beagleboard.org/hardware/design
Looking at the beagleboard Bill of materials at a beagleboard is constructed from 67 different components totalling 230 pieces (lots of caps!). That someone needs source, assemble and *test* before shipping out to customers. So even if the cost of material would be $25, you still need to count that not every board manufactured will work, mail will loose products and people will RMA boards that slipped your testing - all adding up to the cost.
Bits from BB manufacturing:
http://jkridner.s3.amazonaws.com/esc/BEAGLE_ESC_4.ppt
Will remain interested to hear the BoM of Rasberry and how they get manufacturing done without pushing the price up.
Posted Mar 6, 2012 8:00 UTC (Tue)
by MKesper (subscriber, #38539)
[Link] (15 responses)
Posted Mar 6, 2012 8:30 UTC (Tue)
by mjr (guest, #6979)
[Link]
To be fair, there wasn't really much choice, and freedom wasn't their main design goal anyway (though it does support the main goal of educational use, but one can argue that it's "free enough" for most in that respect).
As I've said before, hopefully the lima driver project for the mali will take off, then there'll at least be a free alternative. Won't help the Pis at least in this generation, of course. But at least software written for the Pi is written against open APIs and are thus not married to the proprietary GPU.
Posted Mar 6, 2012 9:31 UTC (Tue)
by koenkooi (subscriber, #71861)
[Link] (13 responses)
Posted Mar 6, 2012 12:00 UTC (Tue)
by MKesper (subscriber, #38539)
[Link]
Posted Mar 6, 2012 13:10 UTC (Tue)
by ssvb (guest, #60637)
[Link] (11 responses)
I may be biased, but right now Exynos4 SoC looks like the least "evil" solution to me from the open source perspective. At least in theory :) Especially considering the ongoing open source Mali drivers efforts. But Exynos4 based hardware is a bit pricey.
Posted Mar 6, 2012 13:51 UTC (Tue)
by dufkaf (guest, #10358)
[Link] (10 responses)
Posted Mar 6, 2012 13:59 UTC (Tue)
by dufkaf (guest, #10358)
[Link]
Posted Mar 6, 2012 14:56 UTC (Tue)
by ssvb (guest, #60637)
[Link]
Not really full access. Any hardware registers, which are only readable/writable in the secure state, are locked out and need some support in the ROM API for accessing them from the linux kernel. The comments from Russel King are quite interesting here:
Beagleboard is an amazing project and a real breakthrough for its time. But even more freedom would be definitely nicer and I'm ready to move to a less restricted hardware any time without any regrets, assuming that it is also competitive in other aspects :)
Posted Mar 6, 2012 20:09 UTC (Tue)
by epa (subscriber, #39769)
[Link] (7 responses)
Posted Mar 6, 2012 20:58 UTC (Tue)
by khim (subscriber, #9252)
[Link] (6 responses)
Contemporary GPUs are not well-suitable for this: single-thread performance is abysmal. They really need thousands of threads if your code have many conditional jumps (and “general-purpose” OS have huge number of them). But yes, eventually it should become possible.
Posted Mar 7, 2012 2:14 UTC (Wed)
by bronson (subscriber, #4806)
[Link]
I don't know if others have learned this lesson the hard way but, since the 80s, who hasn't thought at one time or another, "holy crap, look at the throughput on that sucker!! No need for a CPU!"
The convergence is happening but it's taking longer than most people would have guessed.
Posted Mar 7, 2012 11:02 UTC (Wed)
by epa (subscriber, #39769)
[Link] (4 responses)
Posted Mar 7, 2012 13:04 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
With DSP it's probably first, with GPU it's second. Single IF may require hundreds of ticks to handle on contemporary GPUs and their frequency is usually much smaller then frequency of contemporary CPUs. The same processing unit can be used to process other execution threads (that's why you need hundreds of thousands threads to fill the pipeline on GPU with ~1000 execution units), but if it's single-threaded OS… well, 99.99% of GPU power will be spent in waiting.
Posted Mar 7, 2012 14:04 UTC (Wed)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Mar 7, 2012 16:01 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
This is kind of obvious: since there are whole OSes which do everything as “complex HTML pages” (webOS, ChromeOS, B2G, etc) literally any task can be covered by that definition. But even “simple”, “easy” things are in reality quite computationally heavy. Think True-Type rendering: basically unavoidable in contemporary OS and truly ubiquitous, yet very branch-heavy and power-hungry. Sure, you can employ some caching and make it more-or-less bearable, but from power supply POV all such things are kind of useless: significantly more energy-effective way is to add some kind of traditional CPU core.
Posted Mar 7, 2012 17:25 UTC (Wed)
by epa (subscriber, #39769)
[Link]
You are right, though, that it is much more power-efficient to have a traditional CPU core do these things rather than force a big lump of GPU silicon to do tasks it's not well suited for. I was thinking only of making the cheapest hardware possible for something like the Raspberry Pi, which doesn't run from batteries.
(By HTML I meant rendering only, not Javascript execution; these days with reasonably quick Javascript engines even most web applications spend most of their time idling the CPU, waiting for the next keystroke.)
Posted Mar 6, 2012 9:19 UTC (Tue)
by weasel (subscriber, #6031)
[Link] (3 responses)
Posted Mar 6, 2012 11:42 UTC (Tue)
by wookey (guest, #5501)
[Link] (2 responses)
But, hell - it's cheap. Who cares about principles. :-)
Posted Mar 6, 2012 18:41 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
also keep in mind that other than beta samples, they have not shipped anything yet, these software downloads are just mirrors of files available from the distros directly.
Posted Mar 6, 2012 20:06 UTC (Tue)
by weasel (subscriber, #6031)
[Link]
And no, what they distribute on their website isn't just a blob that is available from Debian. And they are distributing this software now, independent of any hardware that may ship in the future.
I'm not saying they should "fold and go away" as you suggest. I'm saying they should get their act together and ship with source at the least when required.
Posted Mar 6, 2012 13:51 UTC (Tue)
by btraynor (guest, #26672)
[Link]
Firstly, I commend Eben Upton and his co-founder for initiating the RaspberryPi project. Ultimately, it will result in greater educational opportunities for many people who are interested in Linux, in embedded development, and who have a great idea for an interesting project but little resources to get started. A couple of comments though:
1) Price. Sure the BeagleBoard is approximately $100; but the parts list, schematics, etc. have always been available allowing anyone with the know how to duplicate it at a cheaper price if they wanted to. I would argue that RaspberryPi owes a huge, huge thanks to the BeagleBoard project. I doubt there would be RPi without the Beagle, as the Beagle and the community that has grown around it has shown that low cost dev boards are very useful. Saying that "somebody in that BeagleBoard value chain has got to be making a pile of money..." is not very responsible though. Statements as such should be backed up with proof. This is not a competition, we're all in this together.
2) Community. The single most important success factor for the RaspberryPi's success will be the community that grows around it. Having watched the elinux.org stats, I can say that the community is off to a great start, as the number of RPi pages has spiked tremendously over the last couple of months. But the interesting thing to me that fosters true success, is when a core set of members of the community with highly advanced knowledge of the board and Linux embraces the technology. The most evident example of this is the BeagleBoard/BeagleBone community. A community needs these people to figure out the really hard problems, be able to communicate the solutions adequately, and to stick around for the long haul to explain things over, and over, and over to every new user that arrives on the scene. I can tell you that in #beagle, I've seen very dedicated community members help people get their SDCards formatted thousands of times. The thing about these hackers who carry the community forward is that (in my experience) they have a passion for freedom. So I'll be interested to watch (and help) the RPi community grow and see where it ends up.
Now if only my board would arrive ;)
Posted Mar 6, 2012 15:03 UTC (Tue)
by karim (subscriber, #114)
[Link] (10 responses)
That said, price is interesting, but the RPi is within the same order of magnitude as the BeagleBone. Plus, the RPi doesn't have a serial connector. And even if it did, you'd still need a USB-to-serial connector and, possibly, an RS232 cable. The Bone has this **AND** a JTAG debugger integrated straight out of the box. The only thing you need is the USB cable that comes with the Bone.
Add up the price of purchasing those pieces and/or assembling them to the RPi and the Bone suddenly won't seem too bad.
Personally I'll get an RPi to get a good hands-on with it, but the Beagles are likely what I'll continue recommending for the type of work I do. If nothing else because of the community that's been built around those.
Posted Mar 6, 2012 15:57 UTC (Tue)
by karim (subscriber, #114)
[Link]
Posted Mar 6, 2012 16:03 UTC (Tue)
by jhhudso (subscriber, #35584)
[Link] (1 responses)
http://elinux.org/Rpi_Low-level_peripherals
Posted Mar 6, 2012 17:12 UTC (Tue)
by karim (subscriber, #114)
[Link]
Right, that's why you don't want to compare a 35$ "development board" with an 89$ Development Board (capitals and quotes intended.)
Even if your 5$ price increase would be accepted at face value, you still haven't factored in the cost of a proper JTAG connection.
Posted Mar 6, 2012 17:49 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (6 responses)
To me, the Raspberry Pi is almost like the ZX81 of our generation -- just enough parts in it to call it a computer, and nothing more. But, to do anything useful, you need to start expanding it. But, the base system is cheap, cheap, cheap! Am I far off in this assessment? How much do the things cost that you'll be connecting to either system? Presumably, you're connecting some form of input and some form of display. What happens when you apply an Amdahl's Law type of focus to the price of a complete, usable system, even if you didn't expand it with serial ports, JTAG, etc. and just stuck to, say, a keyboard, monitor and an SD card? IIRC, a ZX81 wasn't that much less expensive than, say, a Commodore VIC-20 once you considered the price of a cassette recorder and TV to go with it, but their base retail prices had a similar ratio...
Posted Mar 6, 2012 18:49 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
display is any HDMI enabled TV
power is a microUSB wall-wart. I've seen these <$10, but I have a half dozen sitting around the house right now, so I wouldn't necessarily need to buy one (this is the same thing a kindle, and most new cell phones use)
storage is a SD card, these can be <$10
what else do you need for your 'complete, usable system'?
Posted Mar 6, 2012 19:06 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (2 responses)
A BeagleBone goes for $90. So, looking system to system, it's just over a 2:1 ratio: $110 vs. $50.
For many engineering geeks, I doubt the $60 differential is a huge deal breaker if you're only buying one. If you're on a much tighter budget, though, or buying many of these (either for many projects, or, say, outfitting for a lab full of students), I can definitely see the lower price being very attractive.
And to point out the obvious, I include the developing world under "much tighter budget." If the goal is to get computers into as many hands worldwide as possible, the BeagleBone is a much harder sell.
If you're just selling to tinkerers that have extra cash, it's hard to see how the Raspberry Pi is dramatically more compelling than the BeagleBone unless your project requires a many boards. I think distinguishing between different goals and scenarios might be helpful for evaluating their relative strengths.
Posted Mar 6, 2012 19:49 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
Also, many people will have stray keyboards and mice around.
Posted Mar 6, 2012 20:33 UTC (Tue)
by jzbiciak (guest, #5246)
[Link]
And sure, you may have a spare keyboard or USB power adaptor around (many tinkerers will), and that makes a difference when you're buying one or two to tinker with. My point is that you can't really count on that if you're, say, outfitting a classroom or doing some other mass deployment.
That brings me back to the final point I was trying to make: Tease apart the different scenarios where you might be choosing between these, and see how the strengths and weaknesses of each play into those scenarios. Reading through these threads, I see a bunch of goalpost shifting, because different commentators are assuming different use scenarios.
Posted Mar 6, 2012 19:25 UTC (Tue)
by gmaxwell (guest, #30048)
[Link] (1 responses)
Except for the fact that that most of the transistors in the main chip are locked up in a completely proprietary DSP which is why the devices needs an 18MByte binary blob to even boot.
...and the ARM CPU (really a coprocessor) is anemic enough that without this DSP there is basically no hope of reasonable video decoding on this platform.
Pretty lame from the perspective of an expirementer's platform, really.
Posted Mar 9, 2012 22:16 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link]
CPUs are general purpose, but that doesn't mean they're maximally efficient for all workloads, especially insanely parallel ones like video decode/3D rendering.
Posted Mar 6, 2012 23:12 UTC (Tue)
by endecotp (guest, #36428)
[Link]
In this case, what got me was the closed MPEG decoder block. It has a driver which downloads a binary blob (actually a DSP executable) for the format that you want to decode, and then shuffles data back and forth in shared memory. But when you get decoded video frames out, they don't include the corresponding timestamp from the input MPEG stream. So the only way to do A/V sync is a hack. If the DSP code were open source, then I could add probably just a few dozen lines to it to propagate the timestamps and everything would be great.
My point is that wanting a free graphics system is not only a moral, philosophical argument, but also a practical issue that gets in the way of making good use of these chips.
If anything, the Raspberry Pi is less open that the alternatives since the closed GPU is "on top". Its proponents also have less excuse for the closed graphics system, since in their case it is their own IP; in most of the other cases the vendor has licensed it from a third party (e.g. TI from PowerVR).
Will someone wake me up when something changes?
Posted Mar 7, 2012 7:40 UTC (Wed)
by geuder (subscriber, #62854)
[Link] (6 responses)
He answers a big part of the question himself. If you employ 10 people here it costs you 10 * 100,000 EUR / year. Engineers a bit more, people running your office a bit less, but don't let's make it too scientific now. That's 1 million EUR / year. If you sell 10,000 boards (because they cost 150 EUR many people will hesitate to actually buy one), that's 100 EUR of salaries per board. After that you start to discuss the BOM.
If you are a charity and work (mainly) with unpaid/sponsored resources who have earned their living and a bit more elsewhere the story is a whole lot different.
So one "pile of money" goes to ordinary engineers like me and many other readers here who enjoy the salaries paid in this industry in industrial countries/western world whatever you'd like to call it. (Of course there are some capitalists that make even a lot more money than we do, but I doubt from selling Pandaboards.) Western engineering salaries are not an issue if you sell 10s of millions of devices. But for everything smaller scale they are the killer.
Disclaimer: I have absolute no idea how many boards are realistically sold. But I have the strong feeling the GTA04 people could really be happy if they could plan with 10,000 pieces.
Posted Mar 7, 2012 9:12 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (5 responses)
Definitely! Right now we are just aiming for 350 pre-orders so we can get some made at a slightly more accessible price.
http://www.handheld-linux.com/wiki.php?page=GTA04%20Group...
(currently at 39% of that target - your order could help :-)
Oh: and we are very close to being able to provide the complete phone: main board, display, misc bits (antenna, speakers etc) and case from shapeways.
http://lists.goldelico.com/pipermail/gta04-owner/2012-Mar...
(sorry for the sales pitch - but it was such a good opening :-)
Posted Mar 7, 2012 11:01 UTC (Wed)
by pboddie (guest, #50784)
[Link]
I think a lot of people are hesitant to put down good money for something that they aren't sure they will be able to use. If people could buy something that serves their basic needs, a lot of the exciting stuff could be added later. Indeed, most people would probably be tempted to get involved purely to do the exciting stuff, not getting the device to make calls and stay on the network and other supposedly less exciting things.
Posted Mar 8, 2012 21:06 UTC (Thu)
by btraynor (guest, #26672)
[Link] (1 responses)
Posted Mar 8, 2012 21:48 UTC (Thu)
by neilbrown (subscriber, #359)
[Link]
http://wiki.openmoko.org/wiki/GTA04_Group_Tour_Donations_Hub
There are people willing to subsidise purchases for probably collaborators.
Posted Mar 8, 2012 22:12 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
In my experience, 3D printing is stout where the walls are thick enough but thin stuff like clip tabs and flanges just break off. Most prototypes I've played with have been rather heavy and screwed together.
Any idea on how these cases will stand up in the real world?
Posted Mar 9, 2012 20:21 UTC (Fri)
by neilbrown (subscriber, #359)
[Link]
See: http://www.youtube.com/watch?v=ybT9kdhmurM
All the case pieces were "printed" by shapeways.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
So porting Ubuntu to RPi is utterly pointless.
The only sane choice is to wait until 512mb models (and maybe multiarch) arrive and then support those.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
All of that may be true, but Canonical is all about Unity and Unity is not going to work with 256mb RAM PERIOD
So porting Ubuntu to RPi is utterly pointless.
As far as I know, Ubuntu Server Edition does not include Unity, or any other desktop environment for that matter.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
So the server edition might work but will be fairly useless and anyways the thing has a powerful GPU and fairly weak CPU and a tiny amount of RAM (it actually has less than 256MB). Not the best specs for a server.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
People should also start to remember that production take time, especially when done in the open.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
And the reality is in the long term the multiarch concept being pushed forward inside Debian and Ubuntu now should make the problems with having to expense and maintain dedicated native build infrastructure for each arch moot.
You appear to be thinking multiarch does more than it does. Multiarch lets you co-install multiple ABI libraries (and headers). It thus simplifies and regularises classical cross-compiling somewhat.
It doesn't solve the problem that you can't run 'armhf/hardfp' binaries (which pass parameters in the VFP registers on a v7 ARM) on an earlier ARM arch device (like the v6 PI various v5 'plugs' and the v4t openmoko and FAS chips) that doesn't _have_ the VFP registers.
In practice there are now two common standards for making ARM binaries (out of far too many possible ways). v5(or v4t)/softvp and v7/hardfp. Those two cover all the arm hardware still available/in use in the world. Most distros have a v7 'hardfp' port for the real world (all phones, tablets, and current hardware) and a v4t or v5 'softfp' port for 'old stuff'. Most distros also have an unofficial/less supported v5 port and Debian is sticking with v4t for now as there are still enough openmoko, (and a few other devices) around to make that a sensible cutoff, as we do our best to be 'universal'.
Those two build flavours still need hardware to be built on and whilst it isn't hard to build v4t or v5 binaries (i.e not using v6 or v7 instructions) on v7 hardware, that ability is nothing to do with multiarch. Cross-building softfp ('armel') binaries on a hardfp ('armhf') system, would use multiarch, but I'm not aware of anyone trying to do this for distribution builds. It's a great way of adding a load of new build failures you could do without.
Multiarch makes it possible to cross-build a distro, but due to the inability to run tests other than via emulation it's always going to be more fragile, so I'm not sure anyone is actually going to use it for this for real distros. Getting some real hardware and building natively is always going to be a better plan IHMO.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
According to this interview on youtube the source code will be available as soon as an OEM announces a device running it. (2:43)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Absence of free drivers is what hinders Free Software in the embedded world enormously.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Well, it may be a bit worse here. The OMAP ROM boots your code and you have full access to whole hardware. Here it is all inside out. The ARM part is just a GPU coprocessor so the GPU first boots its own OS from the card and then gives some RAM to ARM core and enables it. The only part that is free for you to play with is the ARM sandbox with subset of accessible hardware described in http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf One notable missing part here is the video out HW. There appears to be no access to it from ARM core at all. You just have memory mapped framebufer already preconfigured by GPU. Also the SD/MMC slot is missing in the datasheet too.
To me it looks similar to running linux/OtherOS under hypervisor on PS3. Is this worse than having non-upgradable OMAP ROM code? :-)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Oh, sorry, the SD/MMC is there, chapter 5 External Mass Media Controller.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
http://comments.gmane.org/gmane.linux.linaro.announce.boo...
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
The most CPU-intensive, branch-heavy thing in day-to-day use is probably rendering complex HTML pages.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
http://www.amazon.com/UART-Module-Serial-Converter-CP2102...
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Add up the price of purchasing those pieces and/or assembling them to the RPi and the Bone suddenly won't seem too bad.
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
It's Not Free Enough
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
http://www.shapeways.com/shops/slyon
GTA04 and its audience
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
Raspberry Pi interview: Eben Upton reveals all (Linux User)
