Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A birthday present from Broadcom

raspberrypi.org

Post reply on HN
Print view View original

161–170 of 170 posts

Re: A birthday present from Broadcom

#161

Post by userbinator »

georgemcbay wrote: post #49

On the one hand as someone who owns half a dozen Raspberry Pis this is really cool news and I hate to look a gift horse in the mouth. 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.

I looked up the documents on it and Bay Trail is surprisingly open for an Intel SoC... although there's probably still plenty of stuff they won't tell you about.

Re: A birthday present from Broadcom

#162

Post by harwoodr »

hermanhermitage wrote: post #122
ebenupton wrote: post #121

Earlier quoted context omitted.

Figured you'd get a kick out of this release. Should be enough for people to figure out how Andrew's FFT code works.

Terrific release, thanks for all that hard work! (Who would have thought! well that crazy dataflow stuff actually works... :)

Okay - that's freaky seeing Herman and Eben converse on the topic... knowing how hard Herman's been working on reverse engineering the VPU/QPU.

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.

Re: A birthday present from Broadcom

#163

Post by akiselev »

embedded wrote: post #85
akiselev wrote: post #55

Earlier quoted context omitted.

This is almost a universal problem with firmware and chip engineers, who are generally older and more experienced, and thus apparently can't be taught new tricks. There are also issues with bureaucracies in each and every semiconductor company (which are on average decades old) so firmware is usually hot potatoed around by management and ends up lighting the customers' projects on fire almost every damn time. I don't…

Wow, armchair engineer, you sound like you really know what you're talking about. 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?

Let me guess... BCM43xx? If so, what's your email? This armchair engineer has an eratta shit list a mile long for you. You know, yeahs after the first revision.

Re: A birthday present from Broadcom

#165

Post by diydsp »

stephen_g wrote: post #143
bdamm wrote: post #94

Earlier quoted context omitted.

git is overkill for facilities with small groups working in a common area (not hard to imagine if you're in the hardware biz) and all the engineers are used to cvs command syntax..

I'm struggling to think of a situation where Git could be overkill for anything... I've personally used it for hardware and software projects where it was just me, where it was used for small teams (3-5 people), and with hundreds of developers doing on a large code base. It worked well on al of them. The only thing I would not use version control is if you have files that don't change. Everything else should be in so…

Semiconductors, especially VLSI, have a different workflow from most software projects. There are supposed to be as few releases as humanly possibly due to the enormous cost of each release. There are not expected to be a community of developer/designers, each with their own vector of revisions available for development and testing. It is prized to arrive at a single image which is reproduced as many times as possible in practice, rather than in variation, as the lithographic process favors identical reproductions.

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.

Re: A birthday present from Broadcom

#166

Post by MPSimmons »

nitrogen wrote: post #144
bdamm wrote: post #94

Earlier quoted context omitted.

git is overkill for facilities with small groups working in a common area (not hard to imagine if you're in the hardware biz) and all the engineers are used to cvs command syntax..

On my one man team, the very first command I type on a project after mkdir is git init . Everything is logged and timestamped, and it is far from overkill. Git is easy to learn after working with CVS

Agreed. I write lots of small apps by myself, and I use version control to save me from, well, myself.

Re: A birthday present from Broadcom

#167

Post by embedded »

akiselev wrote: post #163
embedded wrote: post #85

Earlier quoted context omitted.

Wow, armchair engineer, you sound like you really know what you're talking about. 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?

Let me guess... BCM43xx? If so, what's your email? This armchair engineer has an eratta shit list a mile long for you. You know, yeahs after the first revision.

I hear you. It's so much worse than you can imagine. By the time the code gets out the door, whether through a dump on the net or even worse, through a channel partner and onto a shelf at Fry's, all the engineers are working on new projects. There is sometimes a six-month lag from the time the code is compiled until it shows up on a store. By then the technology has changed no one gives shit about the old stuff. There is no incentive and certainly no corporate push to go fix the bugs that got shipped. I know I always felt like it would be a simple thing to go patch the code, but it was never a priority for the management.

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.

Re: A birthday present from Broadcom

#168

Post by jotux »

chii wrote: post #156
jotux wrote: post #127

Earlier quoted context omitted.

Why would a large company release the commit history of source code when it could open them up to all kinds of lawsuits? It seems perfectly reasonable for them to release it as a zip.

why would the history of the commit open them up to law suits, but not the final product?

A trivial example would be a commit that shows something was implemented and then later removed because of a patent/IP violation.

    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 ######

Re: A birthday present from Broadcom

#169

Post by eliasmacpherson »

pyre wrote: post #157
nitrogen wrote: post #145

Earlier quoted context omitted.

New names for old ideas.

Based on that, SpaceX isn't a big deal, because of the Apollo program, right?

Especially because of the Apollo program. SpaceX for all its efficiency, just goes to show how far the present and past few generations have dropped the ball.

Re: A birthday present from Broadcom

#170

Post by [deleted] »

embedded wrote: post #167
akiselev wrote: post #163

Earlier quoted context omitted.

Let me guess... BCM43xx? If so, what's your email? This armchair engineer has an eratta shit list a mile long for you. You know, yeahs after the first revision.

I hear you. It's so much worse than you can imagine. By the time the code gets out the door, whether through a dump on the net or even worse, through a channel partner and onto a shelf at Fry's, all the engineers are working on new projects. There is sometimes a six-month lag from the time the code is compiled until it shows up on a store. By then the technology has changed no one gives shit about the old stuff. Ther…

[deleted]
Post reply on HN