Module firmware update through RevPi

[janb]

Hello RevPi Team,

the mechanism by which one can make .fwu images for use with the firmware update function built into the piControl kernel module seems to be missing from the published IODeviceExample (or I did not find it).
I would very much like to use that mechanism, can you give me a hint or say whether it will be published?

Thanks,
Jan

[Mathias]

Hi Jan,
you are right, the code that is used to update the firmware in the DIO is missing in the example.
Our intention was to provide an example for people who want to develop their own module. The code includes the source code needed to communicate with the piControl driver on the RevPi.
We will not publish this firmware update code and we will also not publish the code of the tool used to generate the fwu files.
Kind regards
Mathias

[KarlZeilhofer]

Great question, Jan.

I asked more or less the same on GitHub: https://github.com/RevolutionPi/IODevic ... e/issues/4

I wonder, what Kunbus thinks, the strategy would be for people, that want to develop a RevPi Module? I think the possibility to roll out a new firmware in the field one of the most basic and important functions in an ecosystem. If this code will not be published, a custom module will never integrate as smoothly as an original Kunbus module will do.

@Mathias
My understanding of open source is to enable people, to expand the product diversity, since Kunbus will never be able to supply modules for all the different use cases. With an open source system you get access to the productivity of many, many developers, which in turn support your ecosystem. It could easily be a win-win situation. But with holding back some core features, you will outbreak the volunteers supporting the RevolutionPi. I must admit, I'm a bit obset.

Our Makerboard is on its way, to enable people to easily develop modules with their custom capabilities. All open source - even the toolchain is open source (KiCad).
I really hope, Kunbus knows, what they do, when they announce a PLC as open source. The first 2 words in the title on the Revpi website are open source. So please don't dissapoint us developers, believing in a fully open source industrial system.

Greets, Karl

EDIT: new preview of our Makerboard

[volker]

First of all let me say that Mathias is not making decisions about which parts of KUNBUS IP is published and which is not. So please do not try to argue such a question with him. He simply tried to correctly answer a question from the technical point of view which was asked in the forum and on GitHub.
KUNBUS does indeed welcome and appreciate third party developments and we like indeed what you have done. You also well know that we have offered you personally an immediate transfer of all technical details which (because of low demand and lack of time) not yet have been published but will be published. I cannot remember that you have contacted me personally and asked for technical details of the firmware update tool chain. So I am wondering why you choose the way of public discussion instead of using the offered way of simply phoning me and asking for what you need.
KUBUS also has always stated that our understanding of open source is the following:
We want to publish sources which are necessary for 3rd parties to develop own IP without backward engineering. We DO NOT publish any material which enables 3rd party to simply use KUNBUS IP to rebuild our products. So any item which is not necessary to implement your own ideas but is production knowhow of KUNBUS (like pcb layouts or our resources for materials) is not automatically part of the open source concept as KUNBUS would have absolutely no benefit from that.
With our toolchain for the firmware updater we think that this is nothing which needs to be published because it would be something anyone with common knowledge could work out himself. So if you have constructed a module for the PiBridge which could need software updates, I cannot see any reason why you could not implement your own firmware update mechanisms instead of just copying our IP to save the time for developing your own IP.
Firmware of the IOs and the firmware update mechanisms of KUNBUS are and will be part of security concepts which are not public. If we would open these barn doors for hackers to study our concepts it would be much more difficult to implement secure ways to prevent hackers from injecting malicious code into our firmware. So such things are part of highly confidential partnerships under NDA which we will and have signed with several cooperation partners.
You also should keep in mind that not every 3rd party development is an enrichment to the project. We’ve been in contact with people with absolute weird ideas which would never work out without trouble and thus would cause immense unnecessary support efforts just to come to the conclusion that someone has tried something which is simply (because of missing common expertize) condemned to fail. In most of these cases these people have been private makers trying to make an apple out of a cucumber. You may understand that we would never invest in support for such hopeless efforts.
So again: If anyone is missing information to realize his/her own ideas in combination with this project: You are kindly invited to get in contact with me (use PM if you like). We will discuss your plans and the ways we may support you by realizing these ideas as we have done with Karl.

[KarlZeilhofer]

Dear Volker,

thank you very much for making clear your point about open source. Of course I remember your offer to me that I can contact you for any missing details. But we are not this far to ask very detailed questions.

I have not had a look into the update tool yet. And therefore I have not a real idea, how such an updateprocess integrates in the software. I'm just thinking about Arduino (a very popular microcontroller eco system). They would never have been this successful, if they would have said: "you get the schematics, you get the source code, you geht the IDE, but you have to write your own bootloader or flashing tool."

But I also understand you as a corporation, which has to look for profit. At this point, is there any reason, why not a chineese manufacturer could just build and sell core modules, using your Revpi image, or even DIO modules with your firmware?

I don't really know anything about your security concept. But relaying on a "security by obscurity" concept isn't state of the art. If you are concerned about security, you should only relay on secret keys - not concepts. But I'm sure, you know, what I'm talking about.

Not publishing code for "security reasons" seems to me a bit like a lame excuse. But it is your good right.

I think the big advantage of making a project open source, is that everything is reusable. So your suggestion, that we just should write our own programming tool is doable, but that strategy is missing it's target - in my opinion.

You said, you are not willing to support newbies of the embedded electronics world. If you just publish all the necessary code and provide some minimum description, just as you did for the DIO firmware and the schematics, you can refer such people just to that documents. There shouldn't be any support necessary from Kunbus. But perhaps this is a bit different in real world with all the different sorts of people.

For me as a developer, it is a bit different to understand, what Kunbus is publishing, and what not. What do you claim as your IP which you are not willing to share? How far can we get with a custom module? Is there the chance, that it will behave just like an original Kunbus module, or will there be allways a bad touch on such moduls like "yes, they work in principal, but it is no fun to use them because they don't integrate very well."?

Our first step will be the Makerboard. In hardware it should be perfectly compatible with the RevPi, but in the first step, we will not use it with it. The first project with it will be a standallone solution. So the module works on it's own, and it can then be upgraded in future with a to be connected RevPi Core, to get the benefits of a linux system, if needed.

Perhaps you can answer some concrete questions:
1) When I replace the firmware on my DIO with the self compiled firmware, do I loose anything of the integration, functionality or compatibility other than the serial number?
2) Do you use a custom bootloader, or just a custom flashing tool? I have seen, that one of the Sniff signals goes to the BOOT0 pin, which can start the bootloader, that comes with an STM32 - AFAIK.
3) Is a firmware update trigged from the revpi webinterface, or has it be done via the terminal?
4) Do we have to respect any license isssues with the Makerboard? The schematic is based on the DIO schematic, the layout is very custom except for the provided PCB contour.
5) What of the RevPi will never be published?

Thank you very much, Volker, for your patience reading this.
Greets, Karl

[volker]

We do not agree in what is up to date in security concepts and what is not up to date. But I may assure you that no one would ever get information from Atmel about the inside mechanisms of the crypto chip we are using without signing an NDA. Try to get deep inside information about the security concepts of TeamViewer or even where exactly their servers are located and you will understand what I’m talking about. If we need to implement secure concepts of using certificates in firmware you can be sure we will never publically discuss the code which is checking these certificates for verifying that a firmware is proofed by KUNBUS before starting the firmware update. It is all about balancing the amount of criminal energy against the effort needed to hack protection measures. There are main customers out there buying thousands of units per year who would hate to know thta any one could easily implement malicious code into their devices because KUNBUS has published critical parts of the firmware protection.

I’ll try to answer your questions:
1) Yes you may lose integration, functionality or compatibility depending on your ability to understand and implement fully compatible code. There are also parts which you will never be able to fully implement as these parts are related to the built in crypto chip and unpublished security concepts. E.g. certain software which is not free of charge may not run with such a clone because of missing crypto code. This is the way we do protect from pure cloning our hardware.
2) We use the STM bootloader and custom flashing tools.
3) The firmware update is not yet fully implemented and therefore not yet described and published. Once it is fully implemented it will work automatically with packet updates. Actually it needs a manual process which is reserved for End of Line flashing in the production of our modules.
4) The published schematics and PCB shapes are not protected by any license or patent and thus are free to be used by anyone. The logos “RevPi”, “Revolution Pi”, the design of our enclosures and the logo “powered by raspberry pi” are registered designs or trademarks which need written permission to be used.
5) I have answered this in my general statement about our concept of open source which is not the one of Arduino. Actually we do not publish any material related to the production process of our products (e.g. pcb layouts). We will not encourage 3rd parties to simply copy our hardware by making it easy to use our IP. We do encourage 3rd parties to develop their own products (soft- or hardware) which is compatible to our products and try to deliver every information necessary to do so. The time schedule for publishing material is always defined by KUNBUS and may sometimes be part of direct customer negotiations.

[janb]

Thanks for the clarification.
I will tell our engineering partners to contact you if they deem updates a necessity.

[KarlZeilhofer]

Thanks, Volker.

My first question was about the DIO module and using the published firmware from Kunbus. If you say ths exactly the code that is running on a shipped DIO, then there shouldn't be any difference at all. But as I understand you in this point, I would loose it's usability with paid software? Is there crypto involved? Or did you mean a clone of the RevPi Core? Can a custom module work together with paid software running on the RevPi core? For me are the limits of compatibility a bit unclear.

2nd: sounds good to me. Because a custom flashtool, open source of course, should be doable. I think I understand more or less your point about not publishing this piece of code. But that resides on the RP Core only, right? That means, a DIO module should easily be flashable via the Core and an open source tool. Just to be clear, I don't want to clone your hardware, just trying to understand all the relationships.

Greets, Karl

[volker]

Karl,
let's say there is a software which runs with needs a DIO to make sense. This software is not free of charge. We could possibly protect this software by using a crypto chip in the DIO. Hope this makes sense.

[KarlZeilhofer]

2) We use the STM bootloader and custom flashing tools.

11) I'm a bit confused about that statement. Does the STM bootlaoder support a halfduplex communication via RS485?

12) This statement is also a bit controverse to the statement of Mathias on GitHub, where he said: "But your guess is correct. The code for the firmware update is missing." ( https://github.com/RevolutionPi/IODevic ... -363459029 )

Mathias has descirbed the firmware update process here: viewtopic.php?f=17&t=271
Since the to-be-updated module must sit on the right side of the core, i assume, the loader (running in the core) pulls indirectly the boot0 pin high, via the Sniff1a line of the module
13) Is there a code in the module, which resets the module, so the built in STM32 bootloader can be started?
14) If (3) is anwered with yes: Could it be, that if the update process is interrupted (e.g. by a power loss), that the firmware update cannot be started any more with the procedure described by Mathias (2)?

Thanks for your help,
Karl