Raspberry Pi vs. Beagle Bone Black

[pluggy]

hi pluggy,

Could you try the commonly used perf test for your new BBB:

Code: Select all

time echo "scale=2000;4*a(1)" | bc -l

It takes 17 secs in my overclocked Pi. Would be nice to get an idea if the BBB is indeed faster.

Code: Select all

[email protected]:~# time echo "scale=2000;4*a(1)" | bc -l
3.141592653589793238462643383279502884197169399375105820974944592307\
81640628620899862803482534211706798214808651328230664709384460955058\
22317253594081284811174502841027019385211055596446229489549303819644\
28810975665933446128475648233786783165271201909145648566923460348610\
45432664821339360726024914127372458700660631558817488152092096282925\
40917153643678925903600113305305488204665213841469519415116094330572\
70365759591953092186117381932611793105118548074462379962749567351885\
75272489122793818301194912983367336244065664308602139494639522473719\
07021798609437027705392171762931767523846748184676694051320005681271\
45263560827785771342757789609173637178721468440901224953430146549585\
37105079227968925892354201995611212902196086403441815981362977477130\
99605187072113499999983729780499510597317328160963185950244594553469\
08302642522308253344685035261931188171010003137838752886587533208381\
42061717766914730359825349042875546873115956286388235378759375195778\
18577805321712268066130019278766111959092164201989380952572010654858\
63278865936153381827968230301952035301852968995773622599413891249721\
77528347913151557485724245415069595082953311686172785588907509838175\
46374649393192550604009277016711390098488240128583616035637076601047\
10181942955596198946767837449448255379774726847104047534646208046684\
25906949129331367702898915210475216205696602405803815019351125338243\
00355876402474964732639141992726042699227967823547816360093417216412\
19924586315030286182974555706749838505494588586926995690927210797509\
30295532116534498720275596023648066549911988183479775356636980742654\
25278625518184175746728909777727938000816470600161452491921732172147\
72350141441973568548161361157352552133475741849468438523323907394143\
33454776241686251898356948556209921922218427255025425688767179049460\
16534668049886272327917860857843838279679766814541009538837863609506\
80064225125205117392984896084128488626945604241965285022210661186306\
74427862203919494504712371378696095636437191728746776465757396241389\
086583264599581339047802759008

real	0m14.510s
user	0m14.389s
sys	0m0.031s
[email protected]:~# 

I've installed Debian since I first reported. I assumed you'd want bc installing, since it finished ridiculously fast without it........

[pluggy]

Redoing it with the Default Angstrom Distro, it does it in 11.923. Either powered by USB or external 5V which is somewhat surprising.

[amki]

Lack of technical documentation? You have the Arm side datasheet - not the best in the world, but for educational purposes this lack is again, irrelevant

Well that depends on what you want to teach the majority. Eben Upton stated that the Pi was born because of the lack of basic programming skills in college applicants. Teaching them Scratch won't get them anywhere. If you are lacking basic skills, you need some deeper understanding.
Also in a YouTube commentary I'd need to search for he stated that it was sad that our modern PCs/Gaming Consoles etc. were all closed products and you can't tinker with them.

To stay with your argumentation: So what? The Pi isn't changing anything in this department. To do the most basic things (boot up especially) you need your device to do some dark magic nobody may talk to you about because of Broadcom, exactly the same goes for the devices criticized.
Ok, so I can accept that boot loading is not an area where I can tinker with my Pi. (which is limiting my exploration of basic functionality)

But then again there is the point of technical documentation. Why is it lacking? The Foundation says because of Broadcom. You must admit that here should the first doubts kick in that Broadcom might not be the friendliest vendor to base such a device off.
My point here is that everytime something is lacking the Foundation keeps pointing at Broadcom as the boo guys for keeping everything to themselves while on the other hand using Broadcom stuff for everything they do.
It's a huge achievement to get a 35$ computer on the market but it turns out that other vendors are able to do so too and they don't need to keep everything under NDA so that might be better for education, the main purpose of the Pi.

[Heater]

Whilst I sympathise with the call for truly open systems I think we have to accept the fact that in the modern world much of what we use is not so open. If we were to restrict ourselves to only using devices whose firmware was opensource we would be in great difficulty.

Hard drives, SSDs, SD cards would all be off limits as they all have internal controllers and closed source firmware.

USB devices, serilal adapters, ethernet, wifi etc would have to be left on the shelf for the same reason.

Even many Intel processors would be out of the question as they have reloadable microcode. Never mind that most PC's boot from a closed source BIOS.

If you want a truely open system you are going to have to build it ourself. There are guys working on that of course. Check out the OpenRISC processor design on the opencores web site. Along with all the associated peripheral block designs that are accumulating there. Mind you if you want to use those you are probably going to need to put them into an FPGA. Guess what? Everything about those is closed up tight. Unless you want to get a chip FAB company to make your design a silicon reality.

So, we might want to draw the line between the closed and open parts of the systems we use. I guess you are happy to use the closed source code in SD cards or USB gadgets. Such firmware can be considered as not part of our operating system but part of the device.

What about the Pi? Imagine if you will that the GPU did not have reloadable firmware but rather it was permanently blown into the device at manufacture. Then all is OK, the device is the device and we just use it. It's not clear to me that having reloadable firmware changes that picture much.

Of course the compined GPU hardware and firm ware, as a device, has some kind of programming interface. How well that is documented I don't know. If I understood correctly the Linux drivers that interface to that are open as can be.

In conclution I can't see that the Pi can be accused of being anymore closed that most other gadgets we use.

Always room for improvement though:)

[Heater]

By the way, I have some other ARM boards here, Cortex A8, that use uboot/xboot whatever loaded from a FAT files system. Clearly the processor iteself, or some part of the SoC knows about the FAT files system and how to load and run an executable, xboot etc, from it. I would imagine a Beagle Bone does something similar.

I never hear anyone complaining about the closed nature of those set ups.

Many such devices also have GPU's for which I bet the firmware and drivers are closed.

[amki]

In conclution I can't see that the Pi can be accused of being anymore closed that most other gadgets we use.

But education needs openness. There is a reason why low-level knowledge is fading:

1. Why would I want to know how things work? They are already working!
2. Nobody even wants to tell me how things work so I cannot understand them. The Pi was made to solve that problem, at least Eben Upton stated that. Now the Pi is closed itself... It's only a step to understanding because of that and not fixing the problem of fewer and fewer people understanding how things work.

I get a camera, that's all cool but I have no idea how it works and nobody will tell me because that's inherently secret.
It's a feature just like gaming consoles have new features.

The BBB doesn't solve that problem itself, but it goes farther with the openness, which implies I have the possibilites to understand how more things work. Unfortunately good educational material is missing here.

[Heater]

amki,

I do agree with your points there.

But isn't the Pi a big step in the right direction? If I understand correctly in recent decades schools have been decked out in Windows PCs and Macs which are of course a lot more closed. And any computing education revolved around word processors and spreadsheets, which is pretty hopeless. Meanwhile kids at home, as Eben points out, had games consoles which were not programmable at all and PCs which were untouchable as dad would get very uset if it gets broken.

It is said that other manufacturers can produce Pi like boards for a similar price that may be a bit more open. If I recall correctly there were none when the Pi was being dreamed up. It almost looks to me as if the Pi actually inspired a lot of that market activity.

As for the "Why would I want to know how things work? They are already working!" idea. Yes that is pretty terrible. Sadly it applies to just about everything we touch now a days not just computing devices. I don't need to know about radio waves, we have radios they just work. I don't need to know how to make that plastic pop bottle, we have them. Anyone here got any idea how to make that LCD monitor they are reading this on? Or make a blue LED?

It's a long road, this education problem, and much wider than just programming.

[OtherCrashOverride]

Clearly the processor iteself, or some part of the SoC knows about the FAT files system and how to load and run an executable, xboot etc, from it.

FAT has been around since the days of 8 bit computers. Its design and operation are simple compared to modern journaled filesystems. Its for this reason it is chosen as its trivial to include the code in a ROM on the device. SD cards use a high level command stream to communicate as they include a processor of their own to handle low level tasks. The result is that ARM SoCs intended for consumer use are mask programmed with a ROM that instructs the processor to load binary information from a FAT formatted SD card and execute it. Since the code in memory is permanent and non flashable, it is not possible to "brick" these devices.

[abishur]

Lack of technical documentation? You have the Arm side datasheet - not the best in the world, but for educational purposes this lack is again, irrelevant

Well that depends on what you want to teach the majority. Eben Upton stated that the Pi was born because of the lack of basic programming skills in college applicants. Teaching them Scratch won't get them anywhere. If you are lacking basic skills, you need some deeper understanding.

Ok, so I can accept that boot loading is not an area where I can tinker with my Pi. (which is limiting my exploration of basic functionality)

But then again there is the point of technical documentation. Why is it lacking?

Three quick questions

1) Can you in a single sentence describe what is Closed source on the pi? (You haven't mentioned it yet in your posts)

2) What specific aspect of the technical documentation have you personally been limited by by not having? Can you justify that (I.e. Saying your limited just because you don't have it isn't really evidence, but being limited because you wanted to do item X is legit)

3) You seem to making a case that all the pi can do without removing the last layer of closed source bits is teach scratch. Maybe you're really trying to say it's limited to basic skills, in which case I again have to ask, how have you personally been limited from learning programming by the restricted bits. Or to expand it out, can you give a case scenario in which a hypothetical person would be limited from learning programming?

[jamesh]

Lack of technical documentation? You have the Arm side datasheet - not the best in the world, but for educational purposes this lack is again, irrelevant

Well that depends on what you want to teach the majority. Eben Upton stated that the Pi was born because of the lack of basic programming skills in college applicants. Teaching them Scratch won't get them anywhere. If you are lacking basic skills, you need some deeper understanding.
Also in a YouTube commentary I'd need to search for he stated that it was sad that our modern PCs/Gaming Consoles etc. were all closed products and you can't tinker with them.

To stay with your argumentation: So what? The Pi isn't changing anything in this department. To do the most basic things (boot up especially) you need your device to do some dark magic nobody may talk to you about because of Broadcom, exactly the same goes for the devices criticized.
Ok, so I can accept that boot loading is not an area where I can tinker with my Pi. (which is limiting my exploration of basic functionality)

But then again there is the point of technical documentation. Why is it lacking? The Foundation says because of Broadcom. You must admit that here should the first doubts kick in that Broadcom might not be the friendliest vendor to base such a device off.
My point here is that everytime something is lacking the Foundation keeps pointing at Broadcom as the boo guys for keeping everything to themselves while on the other hand using Broadcom stuff for everything they do.
It's a huge achievement to get a 35$ computer on the market but it turns out that other vendors are able to do so too and they don't need to keep everything under NDA so that might be better for education, the main purpose of the Pi.

Yet another post showing a complete lack of understanding of what the Raspi is capable of, claiming its closed nature (ha!) prevents it from doing exactly what is ALREADY BEING DONE with it. You only have to look at the huge number of fascinating projects being done on the Raspi to see that the closed GPU code (the only part of the device that is closed) has had NO effect on the huge majority of people who just need a small device that works.

Not other vendor has a $35 device on the market with the capabilities of the Raspi. Even after a year.

[Heater]

Speaking of education...

Lets's go back to a dark and desperate time long ago when most software available to most people was closed source and a huge empire ruled with an iron grip all the PC's of the world. A young university student had the crazy idea that he was going to learn all about the complex world of virtual memory, and memory management available in the predominant microprocessor from Intel at the time. This was pretty ambitious as such features were not used by the main stream operating systems of the time despite having been around for some years (From the 286 and up), documentation was sparse and it's just plain hard. I know because I had reason make use of the same features profesionally at the time.

Soon our brave young student, undaunted by the obstacles in his path, had a basic operating system running, multi-tasking, protected memory, a file system and a terminal driver.

That young geek was Linus Torvalds and his OS was Linux, as you probably guessed, which went on to take on and overthrow the mighty dark empires and provide an open system for us all. A system that we could study, take apart rebuild modify and enhance, a process my which it contunually improves.

Comming back to today. If a similary smart and enthusiatic young guy (or girl, why not) had a Raspberry Pi and his curiousity drove him to want to know all about the GPU and build what migh per chance become the worlds greatest graphical or number crunching system where would he start? What would he have to do? If the answer involves reverse engineering the thing or signing an NDA we have a problem. where would Linux be if all the vast complexity of the instructions for handling protected mode of the Intel processor were undocumented and only available to the likes of MS for operating system development? Surely there would have been no harm in that, after all normal users can do everything they want on their machines without knowing about that right? Wrong.

[jamesh]

Speaking of education...

Lets's go back to a dark and desperate time long ago when most software available to most people was closed source and a huge empire ruled with an iron grip all the PC's of the world. A young university student had the crazy idea that he was going to learn all about the complex world of virtual memory, and memory management available in the predominant microprocessor from Intel at the time. This was pretty ambitious as such features were not used by the main stream operating systems of the time despite having been around for some years (From the 286 and up), documentation was sparse and it's just plain hard. I know because I had reason make use of the same features profesionally at the time.

Soon our brave young student, undaunted by the obstacles in his path, had a basic operating system running, multi-tasking, protected memory, a file system and a terminal driver.

That young geek was Linus Torvalds and his OS was Linux, as you probably guessed, which went on to take on and overthrow the mighty dark empires and provide an open system for us all. A system that we could study, take apart rebuild modify and enhance, a process my which it contunually improves.

Comming back to today. If a similary smart and enthusiatic young guy (or girl, why not) had a Raspberry Pi and his curiousity drove him to want to know all about the GPU and build what migh per chance become the worlds greatest graphical or number crunching system where would he start? What would he have to do? If the answer involves reverse engineering the thing or signing an NDA we have a problem. where would Linux be if all the vast complexity of the instructions for handling protected mode of the Intel processor were undocumented and only available to the likes of MS for operating system development? Surely there would have been no harm in that, after all normal users can do everything they want on their machines without knowing about that right? Wrong.

Strawman argument.

Algorithms for graphics that you run on GPU's are just as easy (in fact easier) to write on the ARM using Linux. Also, PC's had a standard architecture. All GPU's are different. Learn the Videocore, you know about the Videocore, you don't know about Nvidia, or MALI. You are overly constraining yourself.

The only obvious benefit for running stuff on the GPU is speed.

We've had this argument over and over since the Raspi was announced. At no point has the lack of visibility of the GPU source made any difference to the educational aim of the Raspi. People who say it fails as an educational device because of its closed GPU are talking utter nonsense. Just look at what is being done right now. proof (if any were needed) that as an educational device, and as just a device, the Raspi fills its purpose extremely well.

[gritz]

Speaking of education...

Lets's go back to a dark and desperate time long ago when most software available to most people was closed source and a huge empire ruled with an iron grip all the PC's of the world. A young university student had the crazy idea that he was going to learn all about the complex world of virtual memory, and memory management available in the predominant microprocessor from Intel at the time. This was pretty ambitious as such features were not used by the main stream operating systems of the time despite having been around for some years (From the 286 and up), documentation was sparse and it's just plain hard. I know because I had reason make use of the same features profesionally at the time.

Soon our brave young student, undaunted by the obstacles in his path, had a basic operating system running, multi-tasking, protected memory, a file system and a terminal driver.

That young geek was Linus Torvalds and his OS was Linux, as you probably guessed, which went on to take on and overthrow the mighty dark empires and provide an open system for us all. A system that we could study, take apart rebuild modify and enhance, a process my which it contunually improves.

Comming back to today. If a similary smart and enthusiatic young guy (or girl, why not) had a Raspberry Pi and his curiousity drove him to want to know all about the GPU and build what migh per chance become the worlds greatest graphical or number crunching system where would he start? What would he have to do? If the answer involves reverse engineering the thing or signing an NDA we have a problem. where would Linux be if all the vast complexity of the instructions for handling protected mode of the Intel processor were undocumented and only available to the likes of MS for operating system development? Surely there would have been no harm in that, after all normal users can do everything they want on their machines without knowing about that right? Wrong.

I've obviously woken up in a parallel universe this morning, because the one I went to sleep in wasn't like this at all.

[Heater]

That is a good counter argument James.

It's in agreement with my other point of view (I can hold many at the same time) which is that firmware for peripheral devices is as much part of the device as if it had been hard wired into the devices logic or blown into a devices internal ROM. The only difference being that it is loaded from a binary blob at run time and can be updated.

I do agree that for most people learning the ins and outs of this GPU, or any other, is pretty pointless. By the time you have learned how it all works and perhaps developed some code to exploit it it may well have become obsolete. Better to get on with the interface between your apllication or OS code and the GPU/firmware combo. That is why we have OpenGL ES for such things.

The most extreme free or open source supporters migh do well to consider the closed source code in things like the controllers embedded in SD cards, hard drives, network adapters etc. In the extreme they are in a position to modify your files, inject malware into executables, deny you access and so on. Clearly it is not acceptable to use SD cards or other such controllers in your otherwise free software based computer system, you have no control over what they may do. Think that's absurd? Remeber the root kit Sony shipped on CDs? Clearly that can be done with SD cards and other devices as well.

[Heater]

gritz,

I've obviously woken up in a parallel universe this morning, because the one I went to sleep in wasn't like this at all.

Ha, I some times feel like that as well. I'm curious, could you say it which way its different this morning? Did I get some parts of my story wrong? Make some logical errors perhaps?

[jamesh]

That is a good counter argument James.

It's in agreement with my other point of view (I can hold many at the same time) which is that firmware for peripheral devices is as much part of the device as if it had been hard wired into the devices logic or blown into a devices internal ROM. The only difference being that it is loaded from a binary blob at run time and can be updated.

I do agree that for most people learning the ins and outs of this GPU, or any other, is pretty pointless. By the time you have learned how it all works and perhaps developed some code to exploit it it may well have become obsolete. Better to get on with the interface between your apllication or OS code and the GPU/firmware combo. That is why we have OpenGL ES for such things.

The most extreme free or open source supporters migh do well to consider the closed source code in things like the controllers embedded in SD cards, hard drives, network adapters etc. In the extreme they are in a position to modify your files, inject malware into executables, deny you access and so on. Clearly it is not acceptable to use SD cards or other such controllers in your otherwise free software based computer system, you have no control over what they may do. Think that's absurd? Remeber the root kit Sony shipped on CDs? Clearly that can be done with SD cards and other devices as well.

It's interesting that the Raspi could be modified to actually conform to the FSF definition of a fully OSS device.

By making the firmware immutable - i.e. flashing the device permanently with one version of the firmware prior to sale. That makes it in effect a non-changeable system. You cannot upgrade the firmware (for the camera for example). BUT, all the changeable software on the system would be OSS (ie the ARM side code). Hence it's an OSS device. So, in order for the FSF to be happy it's totally OSS, you need to dramatically reduce the functional possibilities of the device. I don't think that is a worthwhile compromise, but Richard Stallman probably does.

[Heater]

I belive you are correct James.

A few years back I atteneded a talk by Richard Stallman and someone posed the question about the boundries of Free Software. Where would he be OK with closed source? Richards answer was that he would rather all software was open and free but that closed source code in the ROMs of embedded systems was acceptable.

So yes, from that, and from statements by the FSF I have seen since it seems that blowing the firmware into the GPU permanently would make everything hunky dory for them.

Trouble is, as you say, that actually cripples the device some what as it cannot be updated and enhanced. And also it misses my point about embedded code, in ROM, being a hazard to your system as much as any closed source driver or whatever. The stance of the FSF on this issue is somewhat self contradictory.

[Heater]

Thinking about it some more the attitude of the FSF that firmware in ROM is OK but loadable firmware is not makes no logical sense what so ever.

Their argument seems to revolve around the fact that code in ROM is immutable which is better somehow. Perhaps for security reasons. Perhaps because it is not user changeable therefore the user need not know how it was programmed.

BUT. Seems to me that I could quite easily verify that my firmware blobs have not been changed. By direct comparison or md5sum or whatever. In that way I could be sure to always use the same code on my device as the day I bought it, for ever. My kernel could check these things prior to loading them. On the Pi I only have to read the SD card, from the Pi or from a PC.

So logically there is no difference between ROMable code and loadable binary blobs.

I conclude that Free Software supporters should accept the firmware binary blob of the Pi and other devices or refuse to ever use devices with closed code inside them.

[plugwash]

There is some interesting discussion of this issue at.

http://lwn.net/Articles/460654/

It's a difficult situation for the FSF, on the one hand if they insisted that everything possiblly resembling softwareon a device was free it would be almost impossible for them to certify ANYTHING. After all how do you prove a chip doesn't contain some software in an on-chip rom that is completely invisible to the user. On the other hand it's very hard to draw a line on what is and isn't "software" without creating perverse incentives where people who want certification take away users freedom so that they can comply with the letter of the rules.

[Heater]

I can see the FSF's dilemma.

Still, on a normal PC we can have updatable firmware in the very processor running our operating system. Not to mention that the thing won't boot without the closed source and updateable BIOS. Never mind the updateable firmware in hard disk drives, SSDs, and God know what else. Without all these things your free and opensource operating system is useless. (Unless you want to start building your own hardware platform).

Meanwhile the Pi is pretty useless without it's GPU firmware. So what? If that is an issue for you then you have a lot more and bigger fish to fry than the Pi.

I get the impression that some people are somewhat confused about the difference between binary blob that ends up being executed by your operating system, e.g. an Nvida graphics driver, and a piece of firmware that sits in another device.

[pluto7777]

I own several other ARM based developer / hobby boards and none of them have even a tenth of the community Raspberry Pi has. Sure the Pi's CPU isn't the fastest thing out there. The Cortex A8 isn't very fast either when you compare it to the A9 or A15. I'm all for the Raspberry Pi foundation adding a newer model when they're ready but I think they need to keep the classic model B as it is classic and jump a few generations forward skipping over the A8.

[Heater]

I totally agree.
No hurry to change everything just because some users are bleating about a few percent speed up they can have with other boards.
The stability and user base of the Pi are some of it's most important assets for it's intended educational role.
Those who need more speed/memory whatever can buy that elsewhere if they really need it. The Pi will have provided them with the knowledge and confidence to tackle any problems they may find with the environments they find there.

[abishur]

It also helps to remember that there are multiple GPU interfaces for the pi that are well documented and fully accessible on the ARM side of life such that that young college kid in your scenario wouldn't be limited from learning anything they wanted to about GPU stuff and would be able to do so in a manner that actually transcended the GPU that was being used such that it was useful knowledge on multiple platforms.

[rattustrattus]

Just one point I bought a beagalbone black and lcd cape, plugged it together powered it up and had a linux machine with a screen in my hand working in a few minutes, I was impressed. Not as impressed as I was with the hardware documentation which came with the board (well on board it has a USB client interface for "ethernet" and disk access) and it came with a load of docs including comprehensive hardware. I was looking at the PI for some hardware work I bought one liked it, but now I think the beagelbone is more appropriate due to docs, a plugable touch screen (3 sizes available got the little one myself) and a whole load of hardware interfacing thats there as standard. This is ignoring the better processor etc. I suppose if you want to "learn" to program get a PI but I think a linux VM on your windows 8 box may be as good or hw look at the beagal board.

[glnds]

I just ran an extensive benchmark comparison between the Raspberry Pi, the BeagleBone Black and the Banana Pi. You can find the results here: http://gleenders.blogspot.be/2014/07/be ... marks.html

As soon as my BBB rev C arrives i will add it to the test....