Hacker News new | past | comments | ask | show | jobs | submit login
RasberryPi release date February 20th (raspberrypi.org)
108 points by aespinoza on Feb 6, 2012 | hide | past | favorite | 53 comments



Wow, looking at the data sheet BroadCom provided has confirmed my worst fears. Comments like:

There are a number of peripherals which are intended to be controlled by the GPU. These are omitted from this datasheet. Accessing these peripherals from the ARM is not recommended.

There is of course no documentation at all for the GPU, if you run Linux on this thing you are at Broadcom's mercy for maybe giving you a binary blob which might run the GPU in an acceptable manner but no promises.

This is such a sad state of affairs. Where a chip company refuses to divulge information that is critical to using their chip.

Say what you want about the OLPC but like Stallman's laptop the damn thing had pretty good documentation on all the parts. I guess its finally time for an open source SOC.


And if you want to run something that isn't Linux, you're completely out of luck with those peripherals, because we will not be told the information needed to write our own drivers. Broadcom are notorious for being shitheads about this kind of thing, although they're not the only ones.


There are a number of peripherals which are intended to be controlled by the GPU. These are omitted from this datasheet. Accessing these peripherals from the ARM is not recommended.

I can understand them not wanting you to access the GPU peripherals from the ARM processor, the GPU can handle out-of-order data access, but the ARM core cannot (although it sounds like you can get around it with some careful programming).

At this stage i'm happy we got anything out of them at all, limited as it may be. A datasheet for the GPU would be great though. But given the progress of Open Source drivers from the groups working with AMD and Nvidia (who are much more forthcoming than the embedded graphics vendors), I can't say I would prefer to wait 3 years for a functioning driver that can handle OpenGL ES 2.0 and accelerated video playback. You'll still need a binary blob in the meantime. And it's not feasible for them to just give away their driver source for free in the meantime, for the same reasons it was never feasible for nvidia or AMD to just open up their proprietary drivers.

I think in time the situation will improve, but you can't expect Raspberry Pi to reverse standard industry practices in a single leap and bound. Give it time, and see this release for what it is: progress.


>And it's not feasible for them to just give away their driver source for free in the meantime, for the same reasons it was never feasible for nvidia or AMD to just open up their proprietary drivers.

Why? For what reason? All they are doing is inconveniencing users and developers alike. I see exactly zero reason to keep drivers closed. Nada. Null. Nobody gains anything by keeping drivers closed. It's a waste of time and resources.


If you open-source your drivers, people can see all the patents you're infringing. Supposedly.

Also, our shader compiler is magic. You wouldn't believe how amazing it is.


Another very good reason to get rid of the unreasonable clusterfuck that are patents. Once and for all.

And magic is there to be shared. I can't even begin to imagine where we, as humanity, could be if people shared their results and benefited from incremental development off each others' discoveries instead of spending uncountable man-hours reinventing the wheel for the seven hundred and three billionth time.


But that is the deal with patents. You disclose what you have done, and in return, for X number of years, anyone who wants to use the method you have published pays you a fee. The alternative to patents is trade secrets.

If anyone could be bothered, you could read all the patents filed by Broadcom and find out anything you wanted to know. Really.


>You disclose what you have done, and in return, for X number of years, anyone who wants to use the method you have published pays you a fee.

Neither am I going to wait X years to use an idea, nor am I going to pay a fee. I want it right here and right now, and nobody should have a right to stop me. I want to build on it, so others in turn can use my discoveries to build even further.

>The alternative to patents is trade secrets.

No, the alternative is that people would realize already that is in no one's prolonged interested to keep discoveries secret, and that collaborative efforts using each others' ideas would lead to exponential growth of technology.

Patents are a detriment to humanity as a whole and its future technological progress, and we need to get rid of them as soon as possible, along with copyright, and erase the whole delusion of "intellectual property" from all books of law. It probably was the worst mistake in the history of mankind.


I want it right here and right now

But don't want to contribute to the cost of R&D. You have fallen into the classic fallacy that because something cost nothing to reproduce, it cost nothing to discover or to build for the first time. At the very least, the people who worked on it deserve to be paid for their time. The people who swept the floor and washed the dishes while they did it deserve to be paid too. Or do you work for nothing? Or do you plan to get paid for what you build on their work?


>You have fallen into the classic fallacy that because something cost nothing to reproduce, it cost nothing to discover or to build for the first time.

I rather think that you are conflating discovery/creation and distribution/usage, which is the classic fallacy people like the content industries try to promote. It's completely irrelevant if the former is hard, costly and time-consuming or a piece of cake. It doesn't have any implications on the latter, which is - as you point out - costless, so it should be promoted and embraced instead of fought against (which is pointless and ultimately futile).

Also, you completely missed my point, which is that I want to build on it so others can build on my discoveries - a loop of mutual positive feedback that would accelerate technological progress by magnitudes. I don't care if some business models no longer work - the advancement of humanity is infinitely more important. Patents stand in the way of that, so we must get rid of them.

I'd like to add that this philosophy is basically the logical extension of the hands-on imperative, a fundamental part of the hacker ethics. Everything that teaches us something about the world and how it works should be free to access and use. If it isn't, make it accessible - by any means necessary.


To protect themselves, to protect their IP, and to save time and resources. Good documentation takes effort.

Plus, have you seen the pattern that played out with the open source drivers for ATI cards? "Oh, if only those ATI bastards would release documentation!" (ATI releases documentation) "Oh, if only those ATI bastards would release example code!" (ATI releases example code) (etc)

This went on. By that point, it doesn't seem like a loss to not bother, unless you're suggesting they could fire the driver team and have the open source community do their work for them.


>To protect themselves

From what? People actually using and improving their drivers?

>to protect their IP

What's the fucking point? What is there to protect? It's what I don't understand in the first place.

>and to save time and resources.

I call bullshit. Opening their drivers would save more time and resources than they could ever hope to save by keeping it closed.

>Good documentation takes effort.

It takes much more effort to reverse engineer stuff. If you can't be assed to write documentation, give us undocumented code (side note: why are you writing undocumented code in the first place?). It's still infinitely better than keeping them closed. Everything is better than keeping them closed.

>Plus, have you seen the pattern that played out with the open source drivers for ATI cards? "Oh, if only those ATI bastards would release documentation!" (ATI releases documentation) "Oh, if only those ATI bastards would release example code!" (ATI releases example code) (etc)

One bad example doesn't prove or disprove anything. As a counterexample, look at the excellent Intel Graphics drivers for GNU/Linux - by far the most reliable graphic drivers I have used; nVidia doesn't even come close, and let's not get started about AMD/ATI. Free and open drivers are still infinitely superior to keeping them closed.

>This went on. By that point, it doesn't seem like a loss to not bother.

How is open sourcing something a bother? It's much more of a bother to keep them closed, for everyone involved, users and developers alike.

>unless you're suggesting they could fire the driver team and have the open source community do their work for them.

I am suggesting that the driver team should not, by any means, be the only ones with access to the source code and the right to fork, modify, fix and improve it. It's stupid and inflexible, and that's something the hard- and software industries have to learn already.


At FUDCon last month, Chris Tyler from Seneca College gave a presentation about the Raspberry Pi. I don't remember his exact quote, but he said that the vast majority of the die space of the chip was devoted to the GPU and it was best to think of the chip as a big awesome GPU with a tiny little ARM core shoved in a corner of the die, almost as an afterthought.

Given that, it certainly is a tragedy that the GPU is completely undocumented.


Yes, I agree that a documented chip is better than an undocumented one.

But I, for one, am ecstatic that I will finally be able put a few boxes here and there around my house for various automation tasks.

Running Linux itself is a HUGE step towards openness. I actually don't care about the GPU.

The closest thing (in price+performance+flexibility) are open-source-compatible routers onto which I can try loading up an openwrt-derived distro (4 MB RAM, 4 MB Flash) or expensive Arduino boards, plug computers etc! This is a giant leap forward, and I am grateful to Raspberry Pi/Broadcom for trying to make a tinkerer-friendly board like this.


Well you would be better off with an Atmel SAM9 or the Marvell chip (used in the Pogoplug). Of course the BeagleBone [1] (OMAP) is $89 and runs Linux (and its shipping now, has a great community, blah blah blah.) The key being the documentation of course. I was hoping for a machine with a usable HDMI implementation that I could run a custom software load on. Can sell a million of those. R.Pi is not that board apparently. I'm looking at the STM32F [2] which is a Cortex M4 design which I am pretty sure I can get a Linux kernel running on (no video) and it should cost about $30 configured as I'd like (ethernet, serial, USB (for hard drive), and an extra 128MB of memory using PSM ram.

[1] http://beagleboard.org/bone

[2] http://www.st.com/internet/evalboard/product/250863.jsp


Linux won't run on a Cortex M4 because the Cortex Mx cores have no MMU. uCLinux, sure.


While the source code for the OMAP GPU drivers appears to be available, it's not Free Software [1].

[1] http://omappedia.org/wiki/Graphics_SDK


aka, a documented chip is better than an undocumented chip- but an undocumented chip is better than no chip at all.


You are 100% correct.

The thing you have to realize is that at this price point we're pretty much at Broadcom's mercy. Comparable chips are not sold as complete boards for $25-$35. They're doing raspberrypi a favor by even selling them at much lower volume than they'd normally sell them.

Aside from Raspberry Pi, No person or company who is not a Broadcom partner shipping millions per year can even buy this chip.


Could someone privately buy more information about the GPU? i.e. does it exist? Is it held private because some vendor OS has paid them for exclusivity rights? I really don't understand the business strategy behind such secrecy.


Broadcom would probably give you GPU documentation under NDA as long as you don't release any code you write and you don't tell anyone how bad their GPU is.


Binary Blob Question

http://www.raspberrypi.org/forum/general-discussion/gpu-bina...

Could there be malicious software embedded in the closed-source drivers?


Most definitely, otherwise opensource software wouldn't be that big of a deal. It's not very probable though, they don't have much to gain by doing it.


What would Broadcom stand to gain?


I know that sounds really paranoid, but I meant it in the context of backdoors

https://www.eff.org/deeplinks/2010/09/government-seeks


After reading about Aurora and Stuxnet, government backdoors don't seem farfetched. But why would they want to backdoor a bunch of cheapskate Linux developers? The cyberwar budget is large, but it's not infinite.


I'm not on board the conspiracy theorists' train, but it seems to me that people interested in Raspberry Pi would be among the most interesting groups to any government agencies.

Think of the fact that people who have acted as "Anonymous", Wikileaks, etc. are all quite techy.

Also the fact that places like HN seem to be much more pro-wikileaks and pro-anon (at least in terms of their goals, if not their methods) than average non-techy people would be.

Even without these crossovers that I think exist, with the nature of modern computers/internet/etc it seems fairly obvious that this is one of the most dangerous areas for future government problems, be it in terms of revolution, or terrorism, or simply generic law breaking. The people with the technical skills to cause problems in these areas are the people with the technical skills to potentially be interested in projects like Raspberry Pi.


Well then what are you waiting for? Start your own chip company.

We get it. Broadcom doesn't release specs for their parts. Their market cap is 20 billion dollars, so all the open source sanctimony won't dent them a bit.


"RasberryPi release date February 20th". No.

FTA: "[T]he boards will be finished on February 20. [...] [Y]ou should be able to buy them before the end of the month."


There's only 10,000 units in this batch. I'm guessing it will be sold out in an hour or two.


I'm under the impression that you can only purchase 1 per person (or per transaction?). So group and bulk buys are out of the question. 10,000 units might last a bit longer than 1-2 hours, but only time will tell.


Just wait a couple of months and you'll probably be able to pick one up on the cheap from people looking to offload something sitting around. These are a lot less powerful and have a lot fewer connectivity options, unless you want to do some soldering, then people are believing. It also doesn't help that the main selling point (accelerated graphics) will be shipping as a binary blob.


These ... have a lot fewer connectivity options, unless you want to do some soldering, then people are believing

There are always a plethora of USB NIC's.

Me, I just want a cheap low power mailserver. Perhaps if XBMC works well enough, there's that too.


I didn't mean things like NICs. Instead I was talking about sensors and such.


The Raspberry Pi is not targeting the Arduino's use case.

Instead the Raspberry Pi is supposed to be an incredibly cheap computer and for that the only sensor you need is a usb keyboard.


This might be what you need: http://www.raspberrypi.org/archives/411


> These are a lot less powerful...

Er... so what do YOU recommend we buy for around $35 instead?


Can't wait; I want a slow ARM test machine for my code. This will be perfect.


Why dont't you just find a cheap Cortex M3 eval board, then?

http://www.amazon.com/SainSmart-STM32F103RBT6-Cortex-M3-Deve...

(example, not an endorsement)

Or hack a Gameboy Advance. ARM hobby boards have existed long before Raspberry Pi. Or is it the linux distro and easy video that's so appealing?


Cortex M3 doesn't have an MMU so it won't run Linux or other desktop style operating systems. Generally they are programmed 'on the bare metal' or with a fairly lightweight RTOS. So depending on what duaneb wants to do it may not be appropriate.

If the idea is just "find out how well my code runs on a slow machine" a OpenWRT box is probably a decent bet. They are often MIPS core based but when programming in a high level language that doesn't really matter.


Good idea. As an embedded guy I don't always assume "testing my code" means running it on Linux.


Well, in this case he speaks of ARM as being the slow option. It seems safe to assume he's coming from x86, PPC, et al.

There are corner cases like DSP and high speed FPGA's, but I'm not aware of any general-purpose embedded chips that make ARM look slow.

Of course, this is only my opinion, having spent the majority of my time with embedded devices at or below 1MHz. Those 72MHz ARM cores are speed demons in comparison!


It's all relative.

The first few ARM chips ran at 4MHz and gave a 12MHz 80286 a severe run for its money.

We're now at 100's of times faster...


You can run Linux just fine on cortex-M3 without MMU (see http://uclinux.org/).


I think the $25 price point is a major draw. Your example board with fewer features is $60...


...and no Broadcom subsidy.

[EDIT] Am I wrong?


I don't know whether the board is subsidized or not, but I suspect most people don't care why it's as cheap as it is.


Yes, you're wrong. We don't get a subsidy or any other special treatment from Broadcom; they are helping us in allowing us to purchase chips in much smaller numbers than they'd usually consider, though. They're also very happy for their engineers to volunteer on the project (we have four or five who chip in) - outside work hours.


I don't get it? Are you saying that Broadcom are paying rpi to have the chips?


That's one way to think about it. Here's another: if you were actually able to get this chip from Broadcom (you're not), and asked for a 10K lot (you can't), do you think the price would let you achieve a $25 BOM?


What's the up side for broadcom though?


Publicity and maybe a tax write-off.


Cortex M3 is an excellent microcontroller, but not much more. It critically lacks a memory manager, meaning it can't run Linux or other full-featured operating systems. You also run into severe memory/flash limits.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: