A birthday present from Broadcom
raspberrypi.org
raspberrypi.org
* BCM21553 VideoCore IV graphics driver source: http://www.broadcom.com/docs/support/videocore/Brcm_Android_...
* BCM21553 VideoCore IV documentation: http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...
edit: FWIW, a friend who works there told me flat-out to just avoid them (I'm job-hunting)
Why "avoid" them?
That is to say: an "open source" license which does not let you redistribute is not an Open Source license at all. Even Microsoft has not tried to mis-use the term instead using "Share Source" for their, thing.
Everyone from Broadcom to Qualcomm (and many more) are guilty of this and it is a very rare treat to find a chip that is well documented with firmware and code examples that work and give you a full picture of what you can do and where the pitfalls are.
There could still be problems with the documentation of the interfaces to different cores or whatever, but that's peanuts to a company like Broadcom. I'd guess they already have very liberal agreements for important IP and the stuff you'd sue over is mostly the closed source silicon.
Ah yes, experience, the bane of all technical projects.
I have worked at lots of hardware companies over the years, and to varying degrees, they universally treat software as the red headed stepchild -- an unfortunate necessity akin to paying taxes, or worse.
And that's why I no longer work for a semiconductor company.
When this old engineer worked on embedded MIPS cores and 802.11[abgn] at Broadcom, everything was under source code control. This was pre-git, so I think we were using cvs. How the hell do you conclude that releasing a zip file means the engineers don't use source code control?
You don't have to have a distributed workflow to occasionally reap the benefits of working with git.
The only thing I would not use version control is if you have files that don't change. Everything else should be in some form of VC (sometimes Git is not the best choice, but it's good for lots of things)
In my estimate, Broadcom is on the cusp of reaching a sublime point I've seen in other, unnamed semiconductor companies, at which the number of combinations and revisions of IP within a family of chips becomes difficult to account for.
So, it's really not even a question of git being overkill - it's a question of whether its source code will persist over many times the length of the proejct. Git will be considered for substitution by those deeply committed to CVS simply after a matter of time, once its institutional bugs have been discovered and patched.
Hey, I like git too. Respecting the needs of others not to spend mental load on learning something they don't want to is often important too.
Is it really worth it to spend time re-training the 15/20 engineers that don't already know git? I don't think so.
I think the way to understand Broadcom is to realise that they are really a whole bunch of smaller startup companies, more are continually being bought and brought into the fold, this messes with their internal company culture, chips may have functional units in them that came from 5 different companies, each with their own coding standards, VCSs, documentation standards etc etc - as a result it's pretty hit and miss and may take a generation or two for a new technology to settle down - I kind of get the impression that there's ongoing friction between the remnants of these companies as they find their way in the new organisation
I'll tell you the really screwy thing about BCM43xx development. We sold reference designs to companies like 3Com and Linksys (before and after acquisition by Cisco), Apple, D-Link, etc. All of them got the same reference design, in theory, but if one of those companies reported a bug in our code, that company would be the only one to get the patched code. As a consequence our code was littered with #ifdef (COMS) or #ifdef (LINKSYS) with specific patches enabled. The other companies, those that hadn't yet discovered the bug, would get updates that we knew were broken. It was terrible for the companies, even worse for the customers of those companies.
Plus there were source releases to those companies and they weren't allowed to know about patches that they didn't receive. So we had a step in our build process called the code transmogrifier. That would go through the code and expand certain C preprocessor symbols so the code no longer contained #ifdef (COMS) or #ifdef (LNIKSYS). That way every company got a different source code release as well. We would do separate compiles of the transmogrified code for each customer.
Then we had all the customization because those companies had fired all their own engineers and instead wanted us to produce a product that was branded "Cisco" or "Linksys". We had to take the exact same code an rebrand copyright strings to make it look like it was written by our customers.
I voted with my feet and left the industry.
As the guy on the chip team who understood software well (or the guy on the software team who understood the gates) I do think there's a somewhat different issue that has to do with schedules: as a chip designer you get to do maybe 1 month a year of creative design and 11 months meeting timing and making damn sure that silicon will really work the first time - by the time you tape out you're really looking forward to that creative bit and about the time you've up to your armpits in it the silicon comes back and the firmware guys are doing bringup - you don't have a lot of time for the firmware guys because they're getting in the way of the cool part of your job, and besides you are sooo done with that chip you slaved over last year
I don't know what the answer is other than making sure you have firmware running on your logic simulator long before tapeout (you should be doing that anyway)
I stand corrected as far as the average age of employees but every time I have interfaced with any level of a silicon company the average age distribution has been skewed pretty high.
My company selling IP rather than hardware makes it a bit easier, but: management is realistic and reasonably versatile. Attitude to proper technologies (e.g. using Github instead of releasing tar bombs over FTP) is good. Documentation is good, bar "don't document that or we will be sued" situations, which are too common. Testing sucks in certain areas but is good in most.
Obviously at my age I don't have much experience, but I thought the alternative view might be nice.
On an unrelated note, x86 looks like RISC compared to this chip assembly language :)
vmul -,H(1,0),3 CLRA ACC
vadd HX(3,0),H(0,0),2 ACC
vasr H(0++,0),HX(2++,0),2 REP 2
;vmov H(0++,0),0 REP 2
vst H(0++,0),(r0+=r3) REP 2
add r0,16
addcmpblt r5,1,r1,loopacrossEach processor has an accumulator that can be cleared (CLRA) or used (ACC).
This code is basically equivalent to the following C code:
uint8 in[2][16];
int16 temp[2][16];
int32 r1,r3,r5;
uint8 *r0;
do {
... code omitted
// vmul -,H(1,0),3 CLRA ACC
// vadd HX(3,0),H(0,0),2 ACC
for(x=0;x<16;x++) {
temp[x]=inb[1][x]*3+in[0][x]+2;
}
//vasr H(0++,0),HX(2++,0),2 REP 2
//vst H(0++,0),(r0+=r3) REP 2
for(y=0;y<2;y++) {
for(x=0;x<16;x++) {
in[y][x] = temp[y][x]>>2;
r0[y*r3+x] = in[y][x];
}
}
// add r0,16
// addcmpblt r5,1,r1,loopacross
r0 += 16;
r5 += 1;
} while (r5<r1);
This project of yours look really cool, https://github.com/peterderivaz/pymeta3
What do you think about http://www.myhdl.org/doku.php ?
1-jan-2003 - bob: added new feature X
5-jan-2003 - bob: Rev 1.0
8-oct-2012 - frank: Turns our X was patented in 2001 but we didn't realize it. Replace feature X with something that doesn't violate patent ######We released a QPU assembler at https://github.com/hermanhermitage/videocoreiv-qpu/blob/mast... a couple of weeks ago. And a reference javascript VPU assembler is due very soon (mirroring the path taken with the QPU assembler).
Because our own work was independent and pre-dates this information by a couple of years (in the case of the VPU), we have some alignment work to do in terms of mnemonics.
This release adds a lot of knowledge to the table - extending our understanding beyond the core instruction sets (which were already well reverse engineered) into a deeper understanding of the various hardware registers.
Not that I'm saying Eben is trying to hide anything - he just works for Broadcom, a company very concerned with their IP.
Either way, I find the release of this info both surprising and awesome.
I created the srcmap index of raspberrypi_userland src tree here:
http://www.srcmap.org/s/sl.htm/p=raspberrypi_userland#c=P&d=...
Hope you guys find it useful.
(Usually it involves the school designing the academic program and shifting when courses are offered (including putting courses in the spring/summer) to accommodate the work term.)
The grandparent appears to go to the University of British Columbia, judging from their profile.
These kind of deals seem to be quite widespread in Canada (just like the above commenter show). I know these private sector <-> teaching organization deals are not well considered in some part of the world, but, in the end, someone who just graduated, but accumulate years of full time working experience have an easier time landing a job at the end, at least for STEM jobs.
Actually, from another viewpoint, for small companies its very beneficial to hire interns; they can be used to work on projects which might be interesting but have low financial returns.
Which leads me to conclude that > 3 month internships should perhaps be allowed only if you're working at a startup, or small-scale shops that can't really (I mean really really) afford to pay you. For a company like Broadcomm, that doesn't make sense.
Of course, this is just my subjective viewpoint. I'm inclined to believe that my sense of justice might be very skewed.
*(The other three would be elders, children and the ones below poverty threshold)
I know the saying is "don't look a gift horse in the mouth", but could it be that their graphics cores are not competitive in pure technical capabilities, so they've decided to compete on open-ness? I'm not really involved in that area of hardware/software.
I'm not sure how relevant that is with regards to performance per watt, but I do know that heat is one of the most expensive (by-)products of electricity.
AMD's chips aren't egregiously power-hungry, they just sell into a market where the product segments are defined by the thermal and electrical limitations of the PCIe expansion card form factor. It will always be the case that the top of the line card draws as much power as can be delivered through the slot and two extra connectors, and as much as can be dissipated through a two-slot cooling system. If AMD can safely operate their chips at a higher temperature, then their cooling system will be a bit more efficient, so their thermal envelope expands a bit and they can increase performance by a few percent.
Early indications are that NVidia's upcoming Maxwell architecture achieves significant efficiency improvements due to being designed with mobile use in mind, but it hasn't yet been demonstrated in a large enough configuration to compare against high-end desktop graphics chips.
AFAIK the only reasons devices aren't run at arbitrarily high temperatures is that material properties change unfavorably, or you risk fires.
Or, approaching things differently, if you're only going to keep your graphics card for two or three years, there's no reason to let the fans spin up to an audible level until the chip reaches at least 80 degrees C.
Addressing a common misconception: fan speed/noise is not directly related to how much the graphics card is heating up the room by. Whether you run the fans at full tilt or you let the chip almost melt, the heat output will depend only on the workload.
I'm curious about the technological history of the VideoCore. The wikipedia page [1] and Broadcom marketing page [2] don't give a lot of information to distinguish it from competing cores (such as ARM's own Mali or nVidia's Tegra line). In fact, the information I see makes it seems pretty run-of-the-mill tech of 5 years ago.
I guess I could RTFM now that it's available :D
Edit/afterthought: none of this really matters actually, as there is no other chip on the market with the BCM2835's capabilities and that is more open-sourced.
[1] http://en.wikipedia.org/wiki/VideoCore [2] http://www.broadcom.com/products/technology/mobmm_videocore....
There's no one thing about V3D which makes it superior to other cores. Just lots of attention to detail at the design, RTL implementation and layout stages.
Intel: 2.5W TDP quad core Atoms with Intel's x86 instruction pipeline and memory management unit have been released as well as a low cost SDR that should be able to dynamically switch between unlicensed, GSM, CDMA, and LTE spectrum. Intel's graphics work is also quickly catching up and will soon start trickling into their low power embedded chips. Intel has also made clear moves with Galileo to open up their technology to the hobbyist engineers.
NVIDIA: The Tegra K1 is out to NVIDIA's partners (supposedly it beats VideoCore and even low end integrated desktop graphics) and they are currently being worked into tablets. NVIDIA also has recently released the i500, their own software defined radio to compete with Intel, and both companies have the resources to end the lock-in that Qualcomm and Broadcom have had in their respective baseband markets. If you're already buying radios from them, it makes sense to get your processor from them too and Broadcom may be trying to hedge against that.
NVIDIA (and maybe Intel) aren't known to be pioneers of open source but they're better than most other Silicon companies and everyone else is really starting to feel the pressure. The problem of supporting many different device configurations is an old one on desktop systems and that problem is only magnified 10x for embedded engineers because of the opacity. With Intel and NVIDIAs expertise on the desktop as they're running full steam ahead into embedded (and kicking ass along the way), they're scary to the old guard.
Intel has a huge workforce dedicated to open source. They fund huge chunks of kernel, Wayland, X and Mesa development, and I'm sure they have engineers on projects throughout the foss stack. Yeah, their hardware is pretty systemically evil patent drivel black box nonsense, and their chipsets are some of the most obscure bullshit ever, but everything past the firmware they do a good job on.
Nvidia on the other hand consistently blows whole stack. Their foss Tegra drivers are always, at most, 2d accelerated, and all their recent contributions to Nouveau (all two of them) are just to make SoCs bootable on novueau so you can install their blob driver.
Meanwhile, technologies like CUDA, GSYNC, PHYSX, etc are all proprietary platform locked messes that hurt open tech in general. So I'd definitely rank them way below Intel on a comparison of openness.
Edit: ah, Eben has turned up here himself :)
Wasn't Intel first by virtue of using their in-house "HD Graphics" hardware in Silvermont (Bay Trail-M and -T)? Regardless, this is a huge thing in the ARM world, and I hope other vendors will begin to open up documentation.
At last!
(b) They demonstrated the Pi running Quake 3 at a reasonable frame rate in 2011. There's a picture of it in the blog post.
(c) The competition rules say "To submit an Entry, and Entrant shall email a link to a public GitHub repository containing the full source code for the Entry..." so just showing the result wouldn't be eligible to win. That and they already know what it looks like, because of (b).
And they are now offering a bounty for the creation (refinement, really) of more free software. Which will benefit the entire community surrounding the RasPi. So that is good. Even if they were offering $10 USD, there might be someone who'll take up the challenge just to get the bragging rights.
I don't know if you are familiar with the embedded world, but a large percentage of the offerings (specifically system on chip or SoC) have NDA requirements for the documentation.
And many of these platforms don't have a decent Linux port, even though they could support it.
Even with SoC vendors such as TI, the graphics core for the OMAP4 (for example) is a binary blob. There is no documentation for that, and no hope that situation to change (in part because TI has exited the mobile phone market).
Please tell us of your mobile platform experience, and what vendors you consider open or closed.
You could look at it that way if you like. But if you compare the rPi to the comparable low-priced educational development boards available when the project started (none). You might conclude that their marketing effort had a good and very real effect on the availability of low-cost edu dev-kits for both Broadcom SoC products and others' as well (like the BBB). So, as both an educator and Open Source advocate, I am fairly pleased with the rPi project, and even if it isn't exactly what I would have wished for I can't imagine how it could have been more successful or had a better result.
For most practical purposes, it didn't. What existed were either inferior to rPi and more expensive (>4x) or approximately equivalent and much more expensive (>8x). It has had a significant positive impact on the way instruction is given.
Also $10,000 is a significant amount of money.
On the other hand, ARM vendors really have to start opening everything up much more than they have or Intel is going to start eating their lunch in the small embedded Linux arena, and I suspect Intel's mobile resurgence with Bay Trail is at least partly behind this "gift" to us all.
"This isn’t the end of the road for us: there are still significant parts of the multimedia hardware on BCM2835 which are only accessible via the blob."
I'm very excited to see what the next year brings.
I'm assuming doing away with the shim means that there is some gain but in practical terms is it likely to be quite minimal? Will there be routines accessible that weren't accessible via the shim?
I'm happy to be proved wrong, and happy that many little 'RasPis' will have an extended lifespan from this decision by your employer. :-)
And yes, I'm not expecting miracles -- even though Broadcom never released their 4.x port, what they demoed on the-teaser-video-that-was-never-followed-up-on seemed "fast enough" for a number of purposes.
I'd love to see Android support, if only for Android's recovery system and read-only system images.
What next, a full BCM2835 datasheet?
To put in the words of Torvalds: "Hey, this time I'm raising a thumb for Broadcom. Good times."
The Lima driver for ARM Mali is open source and runs Quake 3!
But the Lima driver was created by reverse engineering instead of using publicly available documentation.
http://www.raspberrypi.org/archives/5535
a lot of this work goes upstream.
Hopefully this means we'll see proper DRM / Gallium support for the IV & I'm looking forward to seeing what people can come up with now that they have full access to the GPU.
Congrats to Eben & the team - you've done good.
Does anyone have any insight?
The 3-clause BSD is a compromise - we're happy for the stuff to be used but it's nice to get some credit :)
Often code is GPL'd with pricey licenses for commercial applications - which always makes me think twice about investing my time into familiarizing with it.
I'm very impressed they aren't trying to make a quick buck here. It sounds like they have a very innovative long term strategy that will pay off many times over.
I think your competition is also fantastic, as it will encourage people to open source their improvements.
Thank you for all your hard work Dr.Upton
* Okay, so sue us: we launched on February 29. Please don’t sue us.
> Okay, so sue us: we launched on February 29.
> Please don’t sue us.
(The Quake 3 engine is open source and free nowadays, but the assets and maps are not, so you cannot run "Quake 3" without using the demo. So "Quake 3" is non-free.)
The idTech2 and idTech3 engines are standbys of the open sores community--it makes sense to use them for testing graphics drivers. You are far more likely to encounter a bug in your driver than in those engines.
Sure, but you could use any of the many projects built on the open Q3 engine that are actually free as in speech. (And maybe child-friendly)
Also, to be clear: I find it odd, but still a fun endeavor.
So, in our case, these nice people: https://en.wikipedia.org/wiki/Federal_Department_for_Media_H...
Like it or not.