Olimex A10S/A20-OLinuXino boards quite BBB-like

There's a comedian from the Pi community writing in answer to an Olimex blog post about BBB in which he accuses TI of "cheating".  Pretty funny considering all the price and development help that Pi has been receiving from Broadcom.

I'll  never understand the mentality of fanbois.  It's just a board, for goodness sake.  How can a person be so attached to it that they feel hurt when something more advanced appears on the market?  It makes no rational sense at all.

aw, I like the pic of the dog   I've got that EDN article in my queue to read.  I've come across others too who claimed that the BBB BOM is subsidized by TI.  I'm glad I found this FAQ which explains it: http://circuitco.com/support/index.php?title=BeagleBone_Black_FAQ#Why_is_the_BeagleBone_Black_only_.2445.3F 

While we're brainstorming future boards, the recently reopened topic of Guzunty over in the Pi Group makes me want to propose that the next enthusiasts' embedded ARM board also carry an XC9572XL CPLD and foster a community-supplied range of pre-built downloadable cores.

At well under 2 quid even in small volumes, a CPLD would provide very effective product differentiation, somewhat like the PRUs but in a different direction, and at this price it makes no sense to put it on a cape.

This is a bit off topic for this thread, but on the subject of what BBB is missing,

it seems to me they're missing an active bugtracker.  The BBB FAQ points to:

  http://bugs.elinux.org/projects/beagleboneblack

but that tracker has only 2 issues in it, both more than a month old.

There are people reporting difficulties in various blogs on various sites,

but nobody seems to be filing bug reports.  Various people have noted

problems with HDMI audio, for example, but unless you have that issue

in a bug tracker, it's difficult to know what progress is being made or

what release fixes it.

coder27 wrote:

 

it seems to me they're missing an active bugtracker. 

They seem to be missing lots of stuff like that.  They're reasonably responsive in the google group thing and I was thinking they're using that as their bugtracker after a quick look at the elinux one a while back.

I'm not a fan of forums at the best of times, but that google group thing seems to combine the worst of everything and is hugely unfriendly and difficult to use.  It doesn't take a lot to setup bugzilla, or even one of the simpler bugtrackers, but if they're not interested in using it what's the point ?

Morgaine Dinova wrote:

 

While we're brainstorming future boards, the recently reopened topic of Guzunty over in the Pi Group makes me want to propose that the next enthusiasts' embedded ARM board also carry an XC9572XL CPLD and foster a community-supplied range of pre-built downloadable cores.

 

At well under 2 quid even in small volumes, a CPLD would provide very effective product differentiation, somewhat like the PRUs but in a different direction, and at this price it makes no sense to put it on a cape.

Well, if you want to get started you can use a US$10 Adafruit proto cape plus a socketed XC9572XL today   But you need a custom cape for the TQ100 package to get all the I/Os.

It's pretty neat that the now-rather-long-in-the-tooth 9500XL is still going so strong.  As I've said before, I've gotten a lot of use out of that part over the years.  IMO it has a really nice balance with 5 product terms per macro cell (you can get more by stealing from neighbors) and 72 macro cells instead of the usual 64.  Quite a few of my designs ended up with 70 or 71 macro-cells.  Plus it's still the only CPLD I know of that you can still get in a PLCC.  (There are probably some 22V10s around, but they're "C" enough to count.)

John Beetem wrote:

 

Well, if you want to get started you can use a US$10 Adafruit proto cape plus a socketed XC9572XL today

I could probably afford $10.   But actually, I already have a proto cape sitting here unused.

But my point was that 1) a 2-quid XC9572XL on a proto cape that costs 5 times as much isn't a very cost-balanced design, and 2) providing the CPLD on the ARM board would be a product differentiator.

And yes, your regular eulogy for this device has certainly played a part in my interest, aided and abetted by Derek's nice Guzunty board.

Xilinx should pay you both a commission!

Morgaine Dinova wrote:

 

And yes, your regular eulogy for this device has certainly played a part in my interest, aided and abetted by Derek's nice Guzunty board.

 

Xilinx should pay you both a commission!

I would happily accept open documentation on the bit formats as payment in full

John Beetem wrote:

 

I would happily accept open documentation on the bit formats as payment in full

Has any kickstarter ever been organized to reverse-engineer a specific and very popular device?

Morgaine Dinova wrote:

 

John Beetem wrote:

 

I would happily accept open documentation on the bit formats as payment in full

 

Has any kickstarter ever been organized to reverse-engineer a specific and very popular device?

From what I can tell, the problem is not technical but rather legal.  If one were to try to do this Xilinx would at the very least issue a cease-and-desist the first day the kickstarter opened.  Xilinx likes to give customers the idea that it's impossible to reverse-engineer the bitstream, in spite of Tom Kean's 2002 statement that "Lack of design security has long been the skeleton lurking in the closet of the SRAM FPGA industry".  Now that Xilinx allows bitstream encryption, they should publish the format at least for those devices that have bitstream encyption.  However, I don't think that's going to happen until a competitor does and Xilinx loses business because of it.  Maybe Lattice will do it -- they need some way to differentiate their products from Brand X and Brand A.

John Beetem wrote:

 

From what I can tell, the problem is not technical but rather legal.  If one were to try to do this Xilinx would at the very least issue a cease-and-desist the first day the kickstarter opened.

I know that in USA everyone sues everyone else for anything or for nothing, but the answer to that cultural/legal problem is for the reverse-engineering project not to be based in USA.

Reverse-engineering for interoperability has an extremely long pedigree throughout the entire world (even in USA), so as long as no secret information is being used and you stay clear of trademarks and you don't copy the copyrighted documents, I don't see how they could stop a team from exploring the relationship between bitstream as input and CPLD configuration as output.  C&D's can (and should) be ignored as long as the team stays clear of the various types of legal infringement.  Reverse-engineering isn't a legal infringement.

PS. If the expectation is that Xilinx would be litigious despite lack of any type of infringement, EFF and SFLC could be roped in at the start of the project to ensure that it's on firm ground even in USA.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

From what I can tell, the problem is not technical but rather legal.  If one were to try to do this Xilinx would at the very least issue a cease-and-desist the first day the kickstarter opened.

 

I know that in USA everyone sues everyone else for anything or for nothing, but the answer to that cultural/legal problem is for the reverse-engineering project not to be based in USA.

 

Reverse-engineering for interoperability has an extremely long pedigree throughout the entire world (even in USA), so as long as no secret information is being used and you stay clear of trademarks and you don't copy the copyrighted documents, I don't see how they could stop a team from exploring the relationship between bitstream as input and CPLD configuration as output.  C&D's can (and should) be ignored as long as the team stays clear of the various types of legal infringement.  Reverse-engineering isn't a legal infringement.

 

PS. If the expectation is that Xilinx would be litigious despite lack of any type of infringement, EFF and SFLC could be roped in at the start of the project to ensure that it's on firm ground even in USA.

Well, one could "explore the relationship between bitstream as input and CPLD configuration as output" for a small CPLD like an XC9572XL.  One constraint is that it take about a minute to reprogram one of those suckers, and they're only rated for 10,000 erase/program cycles.  Another problem is that Xilinx doesn't really publish the programming specs.  (It does for FPGAs.)  In early software releases, you had to use a Xilinx programming tool to transfer a JEDEC file into the CPLD.  This would mean you had to reverse engineer the tool's behavior to figure out what to send across JTAG -- that would be a mis-use of the tool and violate EULA.  In current software you can use an SVF file, which includes timing information for programming.  You can also find this in some of the BSDL files.  However, examining the Xilinx files to get this data might be a EULA violation if you used it to reverse-engineer the CPLD.

EFF and SFLC are fantastic organizations and do critically important work for digital freedom.  However, they are both very small and have to choose their battles carefully, so they concentrate on battles where they'll be able to help the most people.  I really doubt they'd want to get involved with a fight that would benefit so (apparently) few and already starts in a legally difficult position.

My plan is to continue to write cranky comments whenever appropriate and try to convince companies that they are limiting their customer bases by keeping documentation closed.  I also applaud companies that do provide open access to their chips.  For example, I applaud Cypress for having documented so much of their PSoC architecture and hope that they will soon document the remaining keys needed to unlock the rest of it.  The Open Hardware movement is only just beginning, and once it is seen as representing an large group of customers for chips, companies may understand that it's in their best interests to open architectures so they can sell more chips and at the same time lower their software development costs.  All we need is for one company to do it and have extraordinarily good publicity to come from it.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

From what I can tell, the problem is not technical but rather legal.  If one were to try to do this Xilinx would at the very least issue a cease-and-desist the first day the kickstarter opened.

 

I know that in USA everyone sues everyone else for anything or for nothing, but the answer to that cultural/legal problem is for the reverse-engineering project not to be based in USA.

 

Reverse-engineering for interoperability has an extremely long pedigree throughout the entire world (even in USA), so as long as no secret information is being used and you stay clear of trademarks and you don't copy the copyrighted documents, I don't see how they could stop a team from exploring the relationship between bitstream as input and CPLD configuration as output.  C&D's can (and should) be ignored as long as the team stays clear of the various types of legal infringement.  Reverse-engineering isn't a legal infringement.

 

PS. If the expectation is that Xilinx would be litigious despite lack of any type of infringement, EFF and SFLC could be roped in at the start of the project to ensure that it's on firm ground even in USA.

Well, one could "explore the relationship between bitstream as input and CPLD configuration as output" for a small CPLD like an XC9572XL.  One constraint is that it take about a minute to reprogram one of those suckers, and they're only rated for 10,000 erase/program cycles.  Another problem is that Xilinx doesn't really publish the programming specs.  (It does for FPGAs.)  In early software releases, you had to use a Xilinx programming tool to transfer a JEDEC file into the CPLD.  This would mean you had to reverse engineer the tool's behavior to figure out what to send across JTAG -- that would be a mis-use of the tool and violate EULA.  In current software you can use an SVF file, which includes timing information for programming.  You can also find this in some of the BSDL files.  However, examining the Xilinx files to get this data might be a EULA violation if you used it to reverse-engineer the CPLD.

EFF and SFLC are fantastic organizations and do critically important work for digital freedom.  However, they are both very small and have to choose their battles carefully, so they concentrate on battles where they'll be able to help the most people.  I really doubt they'd want to get involved with a fight that would benefit so (apparently) few and already starts in a legally difficult position.

My plan is to continue to write cranky comments whenever appropriate and try to convince companies that they are limiting their customer bases by keeping documentation closed.  I also applaud companies that do provide open access to their chips.  For example, I applaud Cypress for having documented so much of their PSoC architecture and hope that they will soon document the remaining keys needed to unlock the rest of it.  The Open Hardware movement is only just beginning, and once it is seen as representing an large group of customers for chips, companies may understand that it's in their best interests to open architectures so they can sell more chips and at the same time lower their software development costs.  All we need is for one company to do it and have extraordinarily good publicity to come from it.

John Beetem wrote:

 

However, examining the Xilinx files to get this data might be a EULA violation if you used it to reverse-engineer the CPLD.

Since devices are purchased without needing to sign anything, I think I might offer a suggestion as to what they can do with their EULA.