Pi vs BeagleBone-Black

selsinork wrote:

 

The goal of the Pi is supposedly education, but the assumption that something like this is no great loss is rather flawed. Somehow, somewhere, we need to educate the next generation of programmers in how to write decent USB code or else the number will rapidly dwindle away.  Who gets to make the value judgement that USB isn't worthy ?

 

I think all these things that get dismissed as not important are missed opportunities and we'll simply trade one perceived deficiency for a different one over time.

Hopefully the Pi's USB problems have provided valuable educational lessons for engineers:

• As a SoC designer, don't buy in cheap functionally-subset implementations of design cores for user extensible generic subsystems like USB where you will have no control over user configuration.  Any up-front savings will bite you later, or will bite one of your customers.
• As a board designer with the aim of providing users with full USB functionality, don't choose a SoC that falls foul of the first lesson above.  You will end up with a large development effort as you try to remedy the faults discovered by your users, and there is no guarantee of success even after all your time and money spent.

If even one engineer learns those lessons, something will have been achieved.

Another lesson learned is that you dont beleive your suppliers, or that no matter howmuch testing you do there always something going to go wrong, or you cannot get a device that does everything perfectly for $35 and probably never will. LOt of lessons can be learnt from anything people do.

Can you confirm if any other SoC has a bug free USB system? Or is generally bug free. Ide put money on any of the other small arm boards out there being full of bugs as well, that only come to light once a load of people start to use them. It just the way of the world. ANyone knopw what other socs use the synopsys stuff?

It a problem - when you buy a chip from someone you assume that it works to the spec. ANd when you buy some IP from someone to put in a chip you assume it works as what the supplier says. Because the cost of building it in to a chip is so high. You can test it yourself of course in simulation or fpga, but to test every component on a soc in every possible way is imposibble in a a timescale that gets product on to the market before its out of date. Becuase they are too complicated. You woudl need a team of hundreds of people with millions of dollars worth of kit to test even a subset of a current soc and it would still take a year at least.

selsinork wrote:

 

John Beetem wrote:

 

As with any closed source code, if there's anything wrong with it you can't fix it.  It was this frustration that led RMS to the Four Freedoms.  In the RasPi case, it's apparently working out OK for bare-metal programmers but I'm not following the bare-metal forum either so I don't know if they're exposing problems that require "binary blob" fixes.

Various problems have arisen over time that can only be fixed in the GPU blob. JamesH in particular seems to often dismiss these things with something along the lines of "the gpu binary is closed so nobody can help apart from rpf/broadcom and we're all too busy to look" and seems to combine that with an attitude of the broadcom engineers being the smartest people on the planet and it being impossible for anyone else to be smart enough to help anyway, which I find rather condescending if not outright arrogant.

 

Interestingly, in a thread about the camera, 'gsh' at least hints at having discussions with Broadcom to allow the CSI peripheral details to be added to the arm datasheet. Seemingly to allow others to remove the roadblock of the gpu being the only thing that can talk to the camera/csi and the lack of resource from Broadcom/RPF to do things to the gpu blob.

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=24660&p=346189&hilit=CSI+peripheral&sid=7c21f71bcdec17f98913be74a083680c#p346189

Whether that will ever actually come to anything is anyone's guess, but as at least some sort of acknowledgment that the binary blob can't/won't do everything and that there needs to be other ways it seems significant.

You dont have to be the smartest person on the planet to know that with a closed source buch of software you need to get the owners of the software to work on it and if they are busy then at small sale quantities like the raspberry pis aint gonna get a lot of time. That just tough I guess but Im reckoning that they are the best people to fix stuff anyway, its their code so they know all about it. SUre with time others might be able to help, but that not how the world works.

I thoughthe camera attached straight to the gpu? How woudl the arm talk to the camera if ists actually connected to the gpu?

selsinork wrote:

 

Billy Thornton wrote:

 

Getting stuff out of synopsys is like getting blood out of a stone. But since the number of people who can write decent USB code is pretty small its not a great loss!

Self defeating argument. If the number of people who can write USB code is limited by the number who can get access to the docs necessary to do it.

 

The goal of the Pi is supposedly education, but the assumption that something like this is no great loss is rather flawed. Somehow, somewhere, we need to educate the next generation of programmers in how to write decent USB code or else the number will rapidly dwindle away.  Who gets to make the value judgement that USB isn't worthy ?

 

I think all these things that get dismissed as not important are missed opportunities and we'll simply trade one perceived deficiency for a different one over time.

? I hadnt realised the raspiberrypi was the only device with usb on it. Or are you saying that only people who fix the usb on the raspberry pi are being educated? fixing the usb has nothing to do with education. Someone leanring to code is not going to be able to fix the usb. it woudl have to be an expect in kernel drivers, arm fiqs and usb. Nothing to do with education.

Billy Thornton wrote:

 

I thoughthe camera attached straight to the gpu?

That's what we've been told.

How woudl the arm talk to the camera if ists actually connected to the gpu?

Well that's something we don't know, but may find out in time. 

Consider this, we know that both eth GPU and Arm can talk to the sdcard since the GPU loads code from there before the Arm is given access, we know both the Arm and GPU can access the same i2c channels using the same peripherals - various problems with interactions between the camera and the other channel show this http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=46594&p=367156sid=cf5e12c4e01c81e4484db4a56595cb99#p367156   http://www.raspberrypi.org/phpBB3/viewtopic.php?f=43&t=46299&p=367991&sid=cbfc64ff58b4d45d1b7f489ff0bb0686#p367991  we don't know the internal details, but it seems fair to assume that both the GPU and the Arm have access to all the same peripherals.  However, if that is the case then we only know how to access the ones they've documented for the Arm, there may be other things in the SoC that the Arm can talk to that we simply don't know exist.

The way gsh replied to that thread certainly suggests that the arm can talk to the csi peripheral and that it's simply a matter of getting that documented.  Whether it's any easier to get docs out of broadcom or synopsys I have no idea. Whether what gsh implies in his reply is true or not I have no way of knowing.

Billy Thornton wrote:

 

? I hadnt realised the raspiberrypi was the only device with usb on it. Or are you saying that only people who fix the usb on the raspberry pi are being educated? fixing the usb has nothing to do with education. Someone leanring to code is not going to be able to fix the usb. it woudl have to be an expect in kernel drivers, arm fiqs and usb. Nothing to do with education.

So how do you get to be an expert ?   You're absolutely right that someone starting out is unlikely to fix usb on the Pi, but everyone has to start somewhere.  Just maybe, learning how to tackle the problem from the expert that does fix it, is a step towards someone becoming an expert themselves ?

selsinork wrote:

 

Billy Thornton wrote:

 

? I hadnt realised the raspiberrypi was the only device with usb on it. Or are you saying that only people who fix the usb on the raspberry pi are being educated? fixing the usb has nothing to do with education. Someone leanring to code is not going to be able to fix the usb. it woudl have to be an expect in kernel drivers, arm fiqs and usb. Nothing to do with education.

So how do you get to be an expert ?   You're absolutely right that someone starting out is unlikely to fix usb on the Pi, but everyone has to start somewhere.  Just maybe, learning how to tackle the problem from the expert that does fix it, is a step towards someone becoming an expert themselves ?

I'm not an expert, but I do know some stuff about USB, but not enough to even attempt to try and work on drivers for it. That stuffis  pretty advanced, and i just cant see what use it would have for education. Youre right, everyone has to start somewhere, but you dont learn to drive in a ferrari, you dont learn architecture by building the worlds tallest skyscraper, So real complex stuff doesnt have much purpose in education. But if you really ewant to learn about usb drivers, you really dont need to use a raspberry pi anyway. You can use a linux pc. It late, but I reckon my point is that you yourself said everyone has to start somewhere, and even no usb docs on the raspberry pi does not make the raspberry pi a bad educational device.

My redux from the last few exchanges is that Pi is seen as a vehicle for the initial stages of  engineering education (which of course is true, and very welcome), but owing to the various areas in which the board and SoC are closed, it's not a vehicle for medium or advanced engineering education.  The complex bits are restricted to just a privileged few.  Not ideal, but you can't win them all.

It's a pity though --- it didn't have to be so.  Whatever the obstacles, where there is a will there is always a way, and if the will were there, the whole thing could have been made open hardware.  Or, more optimistically, can still be made fully open hardware some time in the future.  Full disclosure rights to so-called "proprietary IP" can be purchased --- it just requires sufficient will to allocate funds to it, aided by good negotiating skills to convince the design rights holder that their horrible USB design core isn't worth much anyway.

Even the VideoCore will in time become obsolete and superceded by something better.  How about planning for that time, and getting ready to acquire full disclosure rights to it?  Where there is will there is always a way.

selsinork wrote:

 

mynameisJim wrote:

 

It's constantly facinating to me that if the Foundation had chosen to add an eprom and put this information in there where it could never be touched

That's the thing though isn't it. It would need to be a mask programmed rom and inside the SoC.  People have become far to conditioned into the way of thinking that says you can 'flash' the firmware or that rooting your phone or overclocking your device is the done thing for any sort of external chip to survive for long without thorough examination.  If nothing else, the Pi has proven that there's a lot of people out there who are interested in doing things with it that the RPF never considered.

Besides, if they had made the GPU code unchangeable, it seems unlikely that the camera board would have been possible.

Sure the camera board would have been possible, but like you said, it would require a flash of the firmware.  It's kind of an interesting discussion that might be worth splitting into a separate thread, but should we reconsider what does and does not constitute as being open source.  I'm not trying to say that everything on the pi is open, we all know that isn't the case and there's no point in opening that can of beans again, but the boot process does get a lot of criticism for having the level of visibility it does instead of being completely obscured.  As individuals in favour of open source products, I feel like we're almost fighting for things to go the wrong way.  When it comes to ranking something on how open source it is, I think that we should deduct points for hardware obscured code and consider how much usability and configuration we're giving (such as with config.txt) and award such devices for being more open.

Billy Thornton wrote:

 

and even no usb docs on the raspberry pi does not make the raspberry pi a bad educational device.

It doesn't make it a good USB educational device either

I guess what I'm trying to say is that a device, like the Pi, that has problems to be worked out makes an excellent opportunity to learn from a real expert going through the ways to fix them. More so if the expert can document his thoughts and reasoning behind what he does.

The Pi is a bit of a double edged sword here, frustrating that things don't work as we'd like, but an excellent opportunity to learn how to fix them!   Sadly that opportunity is often lost when the interesting bits are unavailable for some reason.