Allwinner R8 in CHIP: now easier to solder

"A big reason that I am a fan of CHIP is that it is Open Source Hardware"

No, the GPU in the R8 is proprietary so you can't use it for anything that the closed drivers don't allow even though the

compute power of the GPU could be useful for several things other than video output. This violates a basic tenant of

open source hardware.

CHIP is Open Source Hardware as the Schematics, Board Layout and Bill of Material are released under an Open Source license.

Next Thing Co has written about their approach to Open Source development:

     https://www.kickstarter.com/projects/1598272670/chip-the-worlds-first-9-computer/posts/1247188

[We] will be working very closely with Free Electrons and the C.H.I.P. Kernel Hacker backers over the next 6 months to make sure C.H.I.P.'s software is open, standard and most importantly FREE.

 

Ultimately, our goal is to have as few binary blobs present in the source tree required to use C.H.I.P. as possible. Presently, binary blobs are required for 3 parts of the R8 SoC software stack:

• ARM Mali 400 Driver (3D graphics acceleration)
• C2D (2D acceleration)
• CedarX (Video Hardware Encoding/Decoding)

 

Our plan is to mainline support for user-space drivers for these binary blobs. But we're also actively exploring ways that we can eliminate the need for these binary blobs altogether. We will also provide Chipsters who want a completely FOSS C.H.I.P. OS builds that are blob-free!

Free Electrons is adding support to the mainline Linux kernel for CHIP including the Allwinner R8: [PATCH 0/5] ARM: sunxi: Introduce CHIP support

They are also upstreaming U-Boot (the bootloader) support: [U-Boot] [PATCH 0/6] ARM: sunxi: Introduce CHIP support

Free Electrons engineer Maxime Ripard posted: "Debian 8 and XFCE running on the CHIP, on top of the DRM / KMS driver!"

For reference:

• Linux kernel: https://github.com/NextThingCo/CHIP-linux
• U-Boot: https://github.com/NextThingCo/CHIP-u-boot
• HW Design Files: https://github.com/NextThingCo/CHIP-Hardware
• Docs: http://docs.nextthing.co/

cheers,

drew

In addition to the three binary blobs required for the Allwinner R8 SoC software stack, the C.H.I.P.'s Realtek RTL8723BS WiFi/Bluetooth module also requires one, correct?

The RTL8723BS is using the Linux kernel driver: RTL871X

https://github.com/torvalds/linux/tree/master/drivers/staging/rtl8712

There is a NextThingCo RTL8723BS repo:

https://github.com/NextThingCo/RTL8723BS

I'm not certain but there may be firmware that gets uploaded to the RTL8723BS hardware by the driver. This would be code executing on the embedded processor in the RTL8723BS.

I noticed this commit comment:

https://github.com/torvalds/linux/commit/c84a7028cc4957e39af5ed8b1a3c8acda24a2a89#diff-a6781a66e7b7b79a23c2d803b720c754

I stand by my original statement, you can't have "open hardware" with closed hardware inside it. GPUs are a particular problem in the ARM SoC world so

everybody shouting "open hardware" does their best to ignore them. Schematics (essential) and board layouts (meh, don't really care about this one) are

a start but it is still the CHIPs that do all the work and without full hardware specs (or in the case of GPUs, ANY hardware specs), they can not be open

hardware. How more obvious can this be ?

The definition of Open Source Hardware requires that editable design files should be published under an Open Source license.  For electronics, this would include schematics, board layout and BOM.  CHIP meets these requirements.

     Open Source Hardware (OSHW) Statement of Principles 1.0

     http://www.oshwa.org/definition/

 

Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design. The hardware’s source, the design from which it is made, is available in the preferred format for making modifications to it. Ideally, open source hardware uses readily-available components and materials, standard processes, open infrastructure, unrestricted content, and open-source design tools to maximize the ability of individuals to make and use hardware. Open source hardware gives people the freedom to control their technology while sharing knowledge and encouraging commerce through the open exchange of designs.

More clarification about the elements of an Open Source Hardware Project:

     Best Practices for Open-Source Hardware 1.0

     http://www.oshwa.org/sharing-best-practices/

Lets hope they manage to create opensource replacements for the graphics/Video accelerator components as they would be generally applicable with any SOC who has that IP included into them..nice one

Gary Stewart wrote:

 

I stand by my original statement, you can't have "open hardware" with closed hardware inside it. GPUs are a particular problem in the ARM SoC world...

The official definition of Open-Source Hardware (OSHW) does not require that everything inside chips be open.  For hardware to be OSHW, it's necessary and sufficient that you have enough documentation to make your own (possibly modified) copies of the board, have permission (license) to do so, and can obtain the chips through ordinary distribution and without NDAs (so you can't use RasPi's BCM2835/36).  The OSHW definition only covers the hardware.  It does not consider whether it's possible to write open-source software for every feature of the chips included in that hardware.

I totally agree that it's a bummer that (most) GPUs and all FPGAs (except for Lattice iCE40) have undocumented internals, and I advocate for open documentation at every opportunity.  However, even with closed GPUs and FPGAs, it's still useful to have OSHW that include those chips and it moves things in the right direction.  Many important examples of OSHW have closed features in their chips: BeagleBoard/Bone (GPU), Novena laptop (GPU and FPGA), and Gadget Factory Papilio FPGA boards.  Yes, it would be wonderful to have their GPUs and FPGAs open, but having OSHW PC boards is a lot better than nothing.

Gary Stewart wrote:

 

I stand by my original statement, you can't have "open hardware" with closed hardware inside it. GPUs are a particular problem in the ARM SoC world...

The official definition of Open-Source Hardware (OSHW) does not require that everything inside chips be open.  For hardware to be OSHW, it's necessary and sufficient that you have enough documentation to make your own (possibly modified) copies of the board, have permission (license) to do so, and can obtain the chips through ordinary distribution and without NDAs (so you can't use RasPi's BCM2835/36).  The OSHW definition only covers the hardware.  It does not consider whether it's possible to write open-source software for every feature of the chips included in that hardware.

I totally agree that it's a bummer that (most) GPUs and all FPGAs (except for Lattice iCE40) have undocumented internals, and I advocate for open documentation at every opportunity.  However, even with closed GPUs and FPGAs, it's still useful to have OSHW that include those chips and it moves things in the right direction.  Many important examples of OSHW have closed features in their chips: BeagleBoard/Bone (GPU), Novena laptop (GPU and FPGA), and Gadget Factory Papilio FPGA boards.  Yes, it would be wonderful to have their GPUs and FPGAs open, but having OSHW PC boards is a lot better than nothing.

Good explanation, johnbeetem.

The Open Source Hardware Certification Version 1 announced in September by OSHWA considers the level of abstraction issue:

many well-known open source hardware projects and products strive towards openness but, by necessity, incorporate non-open components. The open source hardware definition recognizes this reality, and provides guidance on how best to handle non-open components in the context of open source hardware.

It goes on to state:

For the purposes of the certification, openness will be determined by the openness of the contribution made by the creators of the project.  A certified project will be required to share its entire contribution (including the contribution of affiliated corporate entities, if appropriate) in accordance with the open source hardware definition, but not expected to avoid third party closed components beyond its control.

The certification was introduced by OSHWA President Michael Weinberg at the Open Hardware Summit 2015.

Skip to 1h18m in the video:

You don't have permission to edit metadata of this video.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Open Hardware Summit 2015 RE: Allwinner R8 in CHIP: now easier to solder

Poster

Upload Preview

Ok

Cancel

My long term hope is that we will someday have Open Source Hardware at the silicon level from efforts like lowRISC and J Core.

This does also remind me of a very interesting talk from John Sarik & Haig Norian of Columbia University at OHS 2012:

Open Sourcing the Integrated Circuit [PDF]

I have to agree with @gdstew.  It's not open source hardware if it includes proprietary hardware components.  After all, what good is the hardware if you can't write software to run on it!  You can define OSHW any way you please, but in the end the plain English meaning rules in my opinion. 

David Pettit wrote:

 

I have to agree with @gdstew.  It's not open source hardware if it includes proprietary hardware components.  After all, what good is the hardware if you can't write software to run on it!  You can define OSHW any way you please, but in the end the plain English meaning rules in my opinion.

There is a specific definition for Open Source Hardware.  This OSHWA blog post sheds light on how that defination was developed by a community of people creating Open Source Hardware:

    Brief History of Open Source Hardware Organizations and Definitions

    http://www.oshwa.org/research/brief-history-of-open-source-hardware-organizations-and-definitions/

All Open Source Hardware projects and products that I know of include proprietary hardware components: Arduino uses Atmel AVR microcontroller; BeagleBone uses TI Sitara SoC; MinnowBoard uses Intel Atom processor; etc.  I hope that lowRISC will someday provide a physical Open Source processor.

The TI Sitara AM3358 SoC in the BeagleBone Black also has a GPU with no Open Source drivers (Powever SGX).  This is a bummer but I've never actually needed GPU acceleration on the BBB.  The BBB works fine with U-Boot and mainline Linux kernel.

I think that CHIP is in the same situation.  Free Electron engineers along with the Sunxi community are upstreaming CHIP support to U-Boot and mainline Linux kernel.  It would be great to have Mali-400 drivers, but the GPU is not essential to the system.

Closed is not open

War is not peace

...

As I said they ignore the obvious in their definition because otherwise nothing using ARM SoCs is truly open hardware. They can define it (or hide it away) any way they want,

that does not make it open hardware. And it clearly violates the most basic principle of real open hardware.

The AVR hardware is fully documented. A lot of the TI Sitara SoC is fully documented, part of it (the closed hardware GPU part) as you so obviously get is not.

As I stated in the first post, the processing power of GPUs can be used for purposes other than just graphics acceleration but only if they are fully documented. Image processing,

especially in robotics where you don't need video output and could use the fully capable hardware acceleration in the GPU if only it were open, and fast FFTs (it has been done

with RPi since it has an open GPU) are two examples. I am sure that there are more and that there are more than a few people, myself included that do not share your very

limited ideas as to what is and what is not essential hardware in their designs.

A key concept of Open Source Hardware  is the ability to create derivatives.  This is possible with an OSHW board like the BeagleBoard as the schematics, board layout and BOM are published with an Open Source license.  It was also designed to use components that are available in single quantity.  This has resulted in an ecosystem of derivatives including Seeed's BeagleBone Green, Autodesk's Ember, Outernet's Latern and SanCloud.

This discussion though does remind me of the Free Software Foundation's  "Respects Your Freedom" certification program:

All the product software must be free software. The product software includes all software that the seller includes in the product, or provides with the product, or recommends for use in conjunction with the product, or steers users towards installation in the product.

The goal is ensure user freedom and is not concerned with whether the hardware is proprietary.  In fact, the list of certified hardware includes only one product that is Open Source Hardware (Lulzbot TAZ 3d printer).  The only products in the list with GPUs are laptops with integrated Intel graphics, for which there is Open Source GPU driver.

Hi Drew,

I interview to this discussion because I think it is interesting for those who reads without creating a new one. If the arguments become more complex I will open later, but I think you should be involved as per your knowledge in the OSHF. As I mentioned in many other posts the project Meditech is coming to be a "product" aiming to be entirely open for a lot of reasons, first of all the kind of usage. How do you think it is possible to release a product, that is also the result of an integration of different ones, some commercial and some other custom, making it open but maintaining the same sustainable market approach the I have initially provided? Are there specific links between the marketing aspects and the fact that the product is open? You can build, make (maybe) derivatives but you must sell and distribute it at certain specific conditions.

Enrico

Gary Stewart wrote:

 

As I stated in the first post, the processing power of GPUs can be used for purposes other than just graphics acceleration but only if they are fully documented. Image processing, especially in robotics where you don't need video output and could use the fully capable hardware acceleration in the GPU if only it were open, and fast FFTs (it has been done with RPi since it has an open GPU) are two examples. I am sure that there are more and that there are more than a few people, myself included that do not share your very limited ideas as to what is and what is not essential hardware in their designs.

It's terrific that Broadcom has released documentation for the VideoCore IV GPU in RasPi's BCM2835/36.  That's great for open-source software, but on the other hand you can't buy BCM2835/36 chips in small quantities so you can't design small-scale projects that use BCM2835/36 chips -- you have to incorporate a RasPi as a module.  This is a typical quandry in the open-source world: you can get open-source software or open-source hardware, but not both at the same time.

In an ideal world, you would have a choice of fully-documented GPUs and FPGAs.  However, what is documented is up to the silicon vendors which means reality is not ideal and creators of FLOSS and OSHW need to be pragmatic and take advantage of what open-ness can be achieved.  There are many excellent FLOSS and OSHW products out there that are useful even if they're not 100% open.  Using them helps move us up the long road towards the 100% ideal.

Meanwhile, IMO it's important to define clearly what it means to be FLOSS and OSHW today.  Complaining that the definitions aren't "truly open" isn't very helpful IMO, since there aren't "truly open" products available in important sectors.  The established definitions clearly state what users and developers can do with FLOSS and OSHW, and IMO that's very useful.

Thanks for not addressing any of my points in any way with your reply.

The ability to create derivatives is easily available with only a schematic which is why, along with debugging, I call them an essential part of open hardware.

I have never seen any derivative product (there may be a few out there) that actually uses the board layout of the original because they usually try to

differentiate themselves from the original in some way. The BeagleBone Green along with most Aurduino derivatives, many of which do not even use the

AVR processor, are excellent examples. A BOM is a nice time saver but hardly essential in creating a derivative product.

As you point out the definition of open hardware by the OSHW mostly helps those that may be interested in creating derivative products. Other than requiring

that schematics be provided (which some products that are not OSHW "approved" also do) it does not provide any advantage to people that want to use the

product and yet it is constantly used in a way that infers, and sometimes outright claims that it does.

The freedom to use any original or derivative hardware in a way in which may or may not be envisioned by the creator of a product does require that all the

hardware be open. Calling anything else open hardware as if it is an advantage to the user is deceptive at best.

Hi Enrico, I'm not sure I entirely understand your question.  Are you asking what the benefit of making your product Open Source Hardware?  I think the main advantage is that OSHW encourages collaborative development from users/customers.

OSHWA executive director Alicia Gibb wrote a book last year:

Building Open Source Hardware: DIY Manufacturing for Hackers and Makers

It might help answer those questions if I can't.  Alicia did post one of the chapters on the OSHWA mailing list.  Here's the PDF:

http://lists.oshwa.org/pipermail/discuss/attachments/20150916/c1ec8ce5/attachment-0001.pdf

In the context of commercial products and OSHW, I think this recent post from Bare Conductive is interesting:

http://www.bareconductive.com/news/blog-cloning-hardware-isnt-the-hard-part/

We’re a small company with big ideas, but our power lies in the engagement of the thousands of community members that make our products their own and tell us what they think our next step should be. This is the most exciting part of what we do. Do we need high quality hardware to do this? Of course, but that alone is not enough. We also need everything that goes alongside it and that is much harder to copy.

cheers,

drew

I think the problem is overloading the "open source" terminology between what is intuitive for most hardware and software engineers and a much narrower definition for marketing purposes. If the OSHW isn't completely, the they should replace "open" with something like "defined" -- which it really appears to be. Why would you use the term "open" if it isn't?