[U-Boot] changes to U-boot and GPL
We are getting confused when reading the GPL and interpreting how it applies to our situation.
We are adding features (not changing existing ones) to U-boot particular to our in-house developed system which we sell as a product to our customers. These changes involve adding a menu command for common tasks particular to our product and adding an in-house developed protocol for transferring files over a proprietary bus. We do not see these changes as being useful to the general U-boot community. We do have some concerns about security and opening our product (which is safety-critical) for malicious hacking by exposing the modifications.
This modified U-boot will be deployed on our products. It will not make sense to use on any other platforms.
Our question is: Do we need to submit our changes to the U-boot maintainers for inclusion in the mainline distribution code ?
We understand the philosophy of GPL to give our customers the source code so they have the ability to inspect, modify and outsource And customization without being dependent on us.
In that light we have no problem in either providing our customers with the full source code upon their request OR simply load the full source code in the file system of the box it is shipped with. So if a customer wants the code, they can load it of the box they bought from us.
Any suggestions ? Thank you
________________________________ Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Safetran Systems Corp does not accept liability for any damage or loss which may be caused by software viruses. The contents of this e-mail and any attachments are the property of Safetran Systems Corp and are intended for the confidential use by the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other person without written consent. If you are not the addressee, please notify us immediately at the following address: Safetran Systems Corporation, 2400 Nelson Miller Parkway, Louisville, Kentucky 40223. Safetran Systems Corp is a subsidiary of Invensys Plc. Registered office: Portland House, Bressenden Place, London, SW1E 5BF. UK Registered in England and Wales No. 1641421.
On Friday 28 May 2010 13:50:57 Mangelschots, Jef wrote:
We are getting confused when reading the GPL and interpreting how it applies to our situation.
then you should hire a lawyer to interpret it for you. legal advice cannot be obtained from mailing lists such as this. the only thing you can get is random people's opinions. so here is mine ;p.
Do we need to submit our changes to the U-boot maintainers for inclusion in the mainline distribution code ?
this is never a requirement of the GPL for any project out there
We understand the philosophy of GPL to give our customers the source code so they have the ability to inspect, modify and outsource And customization without being dependent on us.
In that light we have no problem in either providing our customers with the full source code upon their request OR simply load the full source code in the file system of the box it is shipped with. So if a customer wants the code, they can load it of the box they bought from us.
and those customers are free to take that source code and release it onto the internet. so your original concerns seem kind of moot. -mike
Dear "Mangelschots, Jef",
In message 226BC4AFA29FC24789DFD00DFF3084C250D369040B@SAFEMAIL.safetran.railad.com you wrote:
We are getting confused when reading the GPL and interpreting how it applies to our situation.
You may want to read "A Practical Guide to GPL Compliance", see http://www.softwarefreedom.org/resources/2008/compliance-guide.html
We are adding features (not changing existing ones) to U-boot particular to our in-house developed system which we sell as a product to our customers. These changes involve adding a menu command for common tasks particular to our product and adding an in-house developed protocol for transferring files over a proprietary bus. We do not see these changes as being useful to the general U-boot community. We do have some concerns about security and opening our
What makes you think they would not be useful? Others might get inspired by your menu system and adjust / extend it for their purposes. U-Boot's origin is from a port to some board thatis of no use to you - and still you benefit from a lot of code you can re-use.
product (which is safety-critical) for malicious hacking by exposing the modifications.
Security by obscurity has never worked, and never will work.
Eventually a peer review from the experts in the community might even help to improve the security of your system (and I mean the real one, not the one you think you have).
But this is your decision, of course.
This modified U-boot will be deployed on our products. It will not make sense to use on any other platforms.
This is your opinion. Other people my think differently.
Our question is: Do we need to submit our changes to the U-boot maintainers for inclusion in the mainline distribution code ?
As Mike already pointed out: no.
We understand the philosophy of GPL to give our customers the source code so they have the ability to inspect, modify and outsource And customization without being dependent on us.
In that light we have no problem in either providing our customers with the full source code upon their request OR simply load the full source code in the file system of the box it is shipped with. So if a customer wants the code, they can load it of the box they bought from us.
Out-of-tree ports have two distinct properties: 1) they are obsolete from day 1 after their release (and often long before that), and 2) they are a never ending maintenance effort. In our experience the most efficient way to optimize product quality while minimizing long-term maintenance efforts is to push all changes into mainline as soon as possible. You get free code reviews from the best experts in the field, the community is maintaining your code for you, and there is free help for you and your customers from the community.
See what's happening with all the out-of-tree ports - people come here asking for help for really ancient versions, and we cannot help even if we want because we don't know the code...
It's your choice.
Best regards,
Wolfgang Denk
We can load binary files by loading them in RAM (offset 0x3000000) first and then copying them to Flash with the cp.b command.
Now we are trying to load our executable (in S-record format) in Flash with the loads command (load S-record) using U-boot.
It is my understanding that S-record files specify the exact location of all data, so I assume that loads will write the content directly to Flash (without the need to load it in RAM first). Is this correct ?
I tried loading an S-record file of which the data is mapped to RAM and that seems to work, But when the S-record file contains records that map a chunk to Flash, it gives the following error:
Unknown command 'S325F8045B0042414E434F4E464947555245445F5354CD' - try 'help' => S325F8045B20415445524154494F4E414C5F5354417E
FYI: 0xf8000000 is the start of our Flash. Our U-boot is based on 2008.10 version.
Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Safetran Systems Corp does not accept liability for any damage or loss which may be caused by software viruses. The contents of this e-mail and any attachments are the property of Safetran Systems Corp and are intended for the confidential use by the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other person without written consent. If you are not the addressee, please notify us immediately at the following address: Safetran Systems Corporation, 2400 Nelson Miller Parkway, Louisville, Kentucky 40223. Safetran Systems Corp is a subsidiary of Invensys Plc. Registered office: Portland House, Bressenden Place, London, SW1E 5BF. UK Registered in England and Wales No. 1641421.
What file transfer protocol do I use when sending an S-record file when I issue the loads command ?
I tried with both TerraTerm and Hyperterminal.
In Terraterm, when I use File | Send File ..., In HyperTerminal, I use the menu Transfer | Send Text File ...
In both these cases, it reads the first line correctly, but by the time it wants to process the following line, it ends up reading garbage. It looks like the terminal programs kept sending bytes while U-boot was processing the first S-record line (which is an S0 record).
I also tried sending a file with the protocols Xmodem, Ymodem, Kermit. Thy do not seem to work, or it is getting garbage (i.e. protocol specific headers, where it expects to see the actual S-record).
Our U-boot is based on 2008.10.
Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Safetran Systems Corp does not accept liability for any damage or loss which may be caused by software viruses. The contents of this e-mail and any attachments are the property of Safetran Systems Corp and are intended for the confidential use by the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other person without written consent. If you are not the addressee, please notify us immediately at the following address: Safetran Systems Corporation, 2400 Nelson Miller Parkway, Louisville, Kentucky 40223. Safetran Systems Corp is a subsidiary of Invensys Plc. Registered office: Portland House, Bressenden Place, London, SW1E 5BF. UK Registered in England and Wales No. 1641421.
On Wed, 2010-08-18 at 10:11 -0700, Mangelschots, Jef wrote:
What file transfer protocol do I use when sending an S-record file when I issue the loads command ?
I tried with both TerraTerm and Hyperterminal.
In Terraterm, when I use File | Send File ..., In HyperTerminal, I use the menu Transfer | Send Text File ...
In both these cases, it reads the first line correctly, but by the time it wants to process the following line, it ends up reading garbage. It looks like the terminal programs kept sending bytes while U-boot was processing the first S-record line (which is an S0 record).
Hmm, sounds like you don't use any flow-control on the serial port so when u-boot goes away to do work it signals the other end(your host running Terraterm/HyperTerminal) to stop transmitting until u-boot's serial fifo has room in it. If Terraterm/HyperTerminal don't have the right flow-control setup then they'll keep tyring to stuff data into the fifo (which gets dropped on the floor).
I also tried sending a file with the protocols Xmodem, Ymodem, Kermit. Thy do not seem to work, or it is getting garbage (i.e. protocol specific headers, where it expects to see the actual S-record).
Our U-boot is based on 2008.10.
Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Safetran Systems Corp does not accept liability for any damage or loss which may be caused by software viruses. The contents of this e-mail and any attachments are the property of Safetran Systems Corp and are intended for the confidential use by the named recipient only. They may be legally privileged and should not be communicated to, or relied upon, by any other person without written consent. If you are not the addressee, please notify us immediately at the following address: Safetran Systems Corporation, 2400 Nelson Miller Parkway, Louisville, Kentucky 40223. Safetran Systems Corp is a subsidiary of Invensys Plc. Registered office: Portland House, Bressenden Place, London, SW1E 5BF. UK Registered in England and Wales No. 1641421. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Peter Barada,
In message 1282151376.23742.30.camel@thunk you wrote:
Hmm, sounds like you don't use any flow-control on the serial port so when u-boot goes away to do work it signals the other end(your host running Terraterm/HyperTerminal) to stop transmitting until u-boot's serial fifo has room in it. If Terraterm/HyperTerminal don't have the right flow-control setup then they'll keep tyring to stuff data into the fifo (which gets dropped on the floor).
Such wild speculations that are not based on personal experience or knowledge are not really helpful.
U-Boot does not implement any kind of flow control on the serial port.
For S-Record download, there is some basic synchronization based on the echo of the input that it sends back (assuming CONFIG_LOADS_ECHO is set in the board configuration), but this requires a terminal emulation that understands how to handle that. This is why the manual recommends "cu" and "kermit".
Best regards,
Wolfgang Denk
Dear "Mangelschots, Jef",
In message 226BC4AFA29FC24789DFD00DFF3084C2524247EDD2@SAFEMAIL.safetran.railad.com you wrote:
What file transfer protocol do I use when sending an S-record file when I issue the loads command ?
There is no protoco. You just send line by line...
I tried with both TerraTerm and Hyperterminal.
Why did you not follow the description in the Manual?
In both these cases, it reads the first line correctly, but by the time it wants to process the following line, it ends up reading garbage. It looks like the terminal programs kept sending bytes while U-boot was processing the first S-record line (which is an S0 record).
Yes. With other terminal emulation programs you may have to twiddle with inter-character and especially inter-line timings.
I also tried sending a file with the protocols Xmodem, Ymodem, Kermit.
loads is not supposed to support xmodem or ymodem or kermit (binary) protocols.
For ymoden, please use the loady command.
For kermit binary protocol, please use the loadb command (recommended: most stable and often fastest of the serial protocols).
Any files attached to this e-mail will have been checked with virus detection software prior to transmission but you should carry out your own virus check before opening any attachment. Safetran Systems Corp does not accept liability for any damage or l
Omit this crap when posting to a public mailing list. If you cannot switch that off, then use a different, neutral mail account for posting to mailing lists.
Best regards,
Wolfgang Denk
participants (4)
-
Mangelschots, Jef -
Mike Frysinger -
Peter Barada -
Wolfgang Denk