[U-Boot] API available to standalone program
Hi All, I am interested to perform some of the functions available from command line calls however called from a standalone application. An example would be fatload mmc .....
I have read all the readme files and looked at the denx documentation as well as mailing lists without finding any info on this other than a bit of talk around function calls possibly making standalone code GPL.
I have come across the "include/exports.h" however the functionality there is useful but limited
I have also come across the "include/api_public.h" which i noticed use to be GPL or BSD but has now changed to just GPL
I have seen within the examples\api directory examples that make use of API functions however i have not been able to replicate this functionality in a standalone program. Can anyone point me to an example or documentation that could help me.
Im also interested in if there was a concious decision to exclude these function calls from standalone applications IE if i am and always will need to write my own code for these functions. I have been attempting to role my own MMC driver for more than 4 weeks now on a processor that has very poor datasheet so i would be very grateful if i was able to use the functionality available in command line calls from within a standalone program.
Thanks in advance for any help Regards, Scott
Dear Scott Anderson,
In message CAFrkK5u5cFhP=66MZ8Z8v_jfgaqap2tae4dk8GBOwPKxHgczyA@mail.gmail.com you wrote:
I am interested to perform some of the functions available from command line calls however called from a standalone application. An example would be fatload mmc .....
Why would you want to do that? Why not just compile your code as part of U-Boot?
Im also interested in if there was a concious decision to exclude these function calls from standalone applications IE if i am and always will need to write my own code for these functions.
Yes, this is an intentional decision. Standalone applications allow you to run any proprietary code you may have, with sufficient glue to allow for an easy start. So for example if you have your own home brew OS or a simple task scheduler or such, you can run it, and even keep it closed source. The price for keeping your code proprietary is a lean, somewhat restrictive interface.
When you want to actually benefit from all estimated 345 years of effort that went into the development of U-Boot (according to [1]), say by using the device drivers, file system code or scripting capabilitiers that come with U-Boot, then you can do so in the context of the GPL license which covers all that code.
Trying to get all the benefits for free, and not contributing anything bac, is something that in my point of view is unethical, which is why we do not support it.
[1] http://www.ohloh.net/p/u-boot
I have been attempting to role my own MMC driver for more than 4 weeks now on a processor that has very poor datasheet so i would be very grateful if i was able to use the functionality available in command line calls from within a standalone program.
You see, this is exactly what I mean: using things like the file system or driver code in a non-GPL standalone application is exactly the type of usage we want to prevent.
If you want to benefit from all the work that the community is offeriung for free, then you are welcome to use it, but please do so in the context of the GPL license so that you not only take from the community, but also give back - no matter how small or big such contribution might be.
Best regards,
Wolfgang Denk
Thank you for the quick reply,
I have entered comments and answers in line below
I am interested to perform some of the functions available from command line calls however called from a standalone application. An example would be fatload mmc .....
Why would you want to do that? Why not just compile your code as part of U-Boot?
Unfortunately this is not an option for me as i am creating a solution for video processing which has IP that relates only to this solution. I am very happy to contribute back to u-boot for any u-boot related functions however want to retain IP for my specific product solution.
Im also interested in if there was a concious decision to exclude these function calls from standalone applications IE if i am and always will need to write my own code for these functions.
Yes, this is an intentional decision. Standalone applications allow you to run any proprietary code you may have, with sufficient glue to allow for an easy start. So for example if you have your own home brew OS or a simple task scheduler or such, you can run it, and even keep it closed source. The price for keeping your code proprietary is a lean, somewhat restrictive interface.
When you want to actually benefit from all estimated 345 years of effort that went into the development of U-Boot (according to [1]), say by using the device drivers, file system code or scripting capabilitiers that come with U-Boot, then you can do so in the context of the GPL license which covers all that code.
Trying to get all the benefits for free, and not contributing anything bac, is something that in my point of view is unethical, which is why we do not support it.
[1] http://www.ohloh.net/p/u-boot
I have been attempting to role my own MMC driver for more than 4 weeks now on a processor that has very poor datasheet so i would be very grateful if i was able to use the functionality available in command line calls from within a standalone program.
You see, this is exactly what I mean: using things like the file system or driver code in a non-GPL standalone application is exactly the type of usage we want to prevent.
If you want to benefit from all the work that the community is offeriung for free, then you are welcome to use it, but please do so in the context of the GPL license so that you not only take from the community, but also give back - no matter how small or big such contribution might be.
This approach is understandable, thank you for explaining the reasoning. It appears that for my solution i will need to write my own drivers or use an operating system which does not impose GPL in this way.
Regards, Scott
On Sat, Jun 14, 2014 at 10:08 PM, Wolfgang Denk wd@denx.de wrote:
Dear Scott Anderson,
In message CAFrkK5u5cFhP=66MZ8Z8v_jfgaqap2tae4dk8GBOwPKxHgczyA@mail.gmail.com you wrote:
I am interested to perform some of the functions available from command line calls however called from a standalone application. An example would be fatload mmc .....
Why would you want to do that? Why not just compile your code as part of U-Boot?
Im also interested in if there was a concious decision to exclude these function calls from standalone applications IE if i am and always will need to write my own code for these functions.
Yes, this is an intentional decision. Standalone applications allow you to run any proprietary code you may have, with sufficient glue to allow for an easy start. So for example if you have your own home brew OS or a simple task scheduler or such, you can run it, and even keep it closed source. The price for keeping your code proprietary is a lean, somewhat restrictive interface.
When you want to actually benefit from all estimated 345 years of effort that went into the development of U-Boot (according to [1]), say by using the device drivers, file system code or scripting capabilitiers that come with U-Boot, then you can do so in the context of the GPL license which covers all that code.
Trying to get all the benefits for free, and not contributing anything bac, is something that in my point of view is unethical, which is why we do not support it.
[1] http://www.ohloh.net/p/u-boot
I have been attempting to role my own MMC driver for more than 4 weeks now on a processor that has very poor datasheet so i would be very grateful if i was able to use the functionality available in command line calls from within a standalone program.
You see, this is exactly what I mean: using things like the file system or driver code in a non-GPL standalone application is exactly the type of usage we want to prevent.
If you want to benefit from all the work that the community is offeriung for free, then you are welcome to use it, but please do so in the context of the GPL license so that you not only take from the community, but also give back - no matter how small or big such contribution might be.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Reader, suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself. - Mark Twain
Dear Scott Anderson,
In message CAFrkK5t+fvyPUwxHwcxvx2ujOt5edbSWcLek3S84TDc7kzfQtw@mail.gmail.com you wrote:
Why would you want to do that? Why not just compile your code as part of U-Boot?
Unfortunately this is not an option for me as i am creating a solution for video processing which has IP that relates only to this solution. I am very happy to contribute back to u-boot for any u-boot related functions however want to retain IP for my specific product solution.
...
This approach is understandable, thank you for explaining the reasoning. It appears that for my solution i will need to write my own drivers or use an operating system which does not impose GPL in this way.
Indeed that sounds like the best approach - U-Boot is a boot loader, and even if it is pretty powerful, it has never been intended as an execution environment for complex application code.
Best regards,
Wolfgang Denk
participants (2)
-
Scott Anderson -
Wolfgang Denk