Raspberry Pi PCB Layout Revealed 112
An anonymous reader writes "Yesterday, the final Raspberry Pi printed circuit board (PCB) layout was revealed. The word 'packed' comes to mind as this is one very complicated looking board. The reason for that is just how much Raspberry Pi has strived to save money on the machine by using complex routing to keep things small and cheap. The Raspberry Pi team don't believe the design is going to change again unless they missed something. With that in mind, they revealed the final board is exactly the same size as a credit card, measuring 85.65 x 53.98mm."
Also that size... (Score:5, Interesting)
Penguins and Altoids tins happen to be about that size as well... I wonder how well a populated Pi will fit... if so, awesome little PC cases!
Re:Complicated? (Score:4, Interesting)
Re:What a wonderful project! (Score:3, Interesting)
all the software is "open" yet obfuscated
The entire Raspberry Pi depends on a gigantic proprietary blob from Broadcom [elinux.org].
So let's do a Nouveau-style reverse engineering project. How hard can it be?
Sounds like a perfect project for the target audience: curious and talented kids. With a bit of experienced help if they get stuck (seems unlikely to me though, with sufficient time & motivation). Some kids love reverse engineering. I did when I was young and I was far from the only one (but we didn't have an internet to meet each other back then).
(I did loads of reverse engineering from about age 11+ (that was 1983), starting with the BBC and moving on to everything I could get access to, pulling apart games (starting from the binaries), changing behaviours, porting them from tape to floppy disk ;-), even porting them to new architectures, and now I think about it, quite a lot of hacking on video hardware of the time, both in hardware, and quirky programming to make it do useful things it wasn't designed to do. If Mr Braben is listening, I printed a whole disassembly of Elite, BBC disk version on dot matrix that took days to print (wow just got a flashback), and spent a long time learning from its algorithms, some of which I still use today - thank you ;-) )
Re:What a wonderful project! (Score:3, Interesting)
The bit about my own history was just to illustrate that young people (the target audience for RP apparently) do take an interest in that sort of thing, not to suggest a method! Of course nobody would use that approach any more! (The Elite reference was because David Braben co-authored Elite and is also involved in RP).
If analysing the blob statically, and if you know the instruction architecture, we have much better tools now, including disassemblers, decompilers, type inference and much more. And internet so we can collaborate better.
16MB is a big blob, but it's highly unlikely that much of it is needed to make a useful open source subset of the functionality.
For perspective on speed: Recently I had to reverse engineer about half of a 1.5MB ARM driver blob in some detail, enough to fix bugs and improve performance deep within it. I'm not going to say what it was, only that it took me about 2 weeks with objdump and some scripts, not using more advanced tools. I didn't enjoy it because it was just to fix some bugs the manufacturer left in :-/ (The best bit was a one-bit change that tripled video playback performance and stopped it stuttering :roll-eyes:)
But there may be a big fat license prohibiting anyone from openly using the results of that type of deep code analysis on the RP's blob.
Plus, there's the secret GPU/RISC architecture to get to grips with; that's not going to be obvious.
So it would probably have to be Nouveau-style: Run the original, watch its interactions with the device (with tracing probes), replay things, change things randomly, try things, gradually build up a picture through guessing as much as anything. That's a much bigger task than statically analysing a blob's code. (At least, to me it seems so.) I don't know whether it's practical on the RP, and I don't know whether it's too difficult. But it worked with Nouveau - and that now supports a lot of nVidia chips - so not to be dismissed as impossible.
You never start all over after a chip rev. That's why they call them revs, not new architectures. You can diff code in blobs if need be; often the changes for a chip rev are very small.
You may be right about needing a lot of 11-year-olds (or others). Luckily the RP is cheap and interesting enough, that it might attract enough interest.
The suggestion isn't all that serious, but nor is it an impossible task, so I think it's worth floating the idea around, see how much interest there is in at least looking further at the practicalities and legalities.
Re:Complicated? (Score:5, Interesting)
Yet other manufacturers don't take that attitude. Go look at TI or Analog devices. Full datasheets right there, often running to hundreds of pages reasonably priced development boards, often free samples. Broadcom claims to have features such as DSP and GPU built in to this chip, but I don't know what use they are supposed to be if they are totally undocumented. Supposedly about 98% of the FLOPS in this thing are in the GPU, but good luck getting at them.
Re:Repeat much? (Score:4, Interesting)
If you want someone to learn how to code efficiently give them an 8-bit microcontroller, not a 32-bit one-point-something GHz CPU with hundreds of MB of RAM.