[U-Boot-Users] [PATCH] Update to stand alone program feature
[PATCH] Update to stand alone program feature
This patch contains updates to the stand alone program feature, including: 1. update and document new features in README.standalone 2. add SA= flag to allow for the stand alone program directory to be selected for compiling with u-boot 3. added xf_func_inc() function. See documentation for a description. 4. removal of undesired #ifdef...#endif statements 5. Note: XF_VERSION was not advanced. This will happen in the next patch
in this series.
This feature does not seem to fall into any category in the list of U-Boot Custodians, so I guess it goes to you, Wolfgang.
The patch file is attached.
-Jeffrey Mann
Patch did not attach. Let me try again...
[PATCH] Update to stand alone program feature
This patch contains updates to the stand alone program feature, including:
- update and document new features in README.standalone 2.
add SA= flag to allow for the stand alone program directory to be selected for compiling with u-boot 3. added xf_func_inc() function. See documentation for a description. 4. removal of undesired #ifdef...#endif statements 5. Note: XF_VERSION was not advanced. This will happen in the next patch
in this series.
This feature does not seem to fall into any category in the list of U-Boot Custodians, so I guess it goes to you, Wolfgang.
The patch file is attached.
-Jeffrey Mann
In message 1628E43D99629C46988BE46087A3FBB997B757@ep-01.EmbeddedPlanet.local you wrote:
Patch did not attach. Let me try again...
...
Content-Type: application/octet-stream; name="stand_alone_prog.patch" Content-Transfer-Encoding: base64 Content-Description: stand_alone_prog.patch Content-Disposition: attachment; filename="stand_alone_prog.patch"
RnJvbSA2MWRhZmE4NzdiNWU1N2RlZDNmNzIzNGY4ZDFkYjFhYjI1OTQyNmRkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKZWZmcmV5IE1hbm4gPG1hbm5qQGVtYmVkZGVkcGxhbmV0LmNv bT4KRGF0ZTogV2VkLCA5IE1heSAyMDA3IDA5OjQyOjU1IC0wNDAwClN1YmplY3Q6IFtQQVRDSF0g VXBkYXRlIHRvIHN0YW5kIGFsb25lIHByb2dyYW0gZmVhdHVyZQoKVGhpcyBwYXRjaCBjb250YWlu cyB1cGRhdGVzIHRvIHRoZSBzdGFuZCBhbG9uZSBwcm9ncmFtIGZlYXR1cmUsIGluY2x1ZGluZzoK MS4gdXBkYXRlIGFuZCBkb2N1bWVudCBuZXcgZmVhdHVyZXMgaW4gUkVBRE1FLnN0YW5kYWxvbmUK Mi4gYWRkIFNBPSBmbGFnIHRvIGFsbG93IGZvciB0aGUgc3RhbmQgYWxvbmUgcHJvZ3JhbSBkaXJl Y3RvcnkgdG8KICAgYmUgY29tcGlsZWQgd2l0aCB1LWJvb3QKMy4gYWRkZWQgeGZfZnVuY19pbmMo KSBmdW5jdGlvbi4gU2VlIGRvY3VtZW50YXRpb24gZm9yIGEgZGVzY3JpcHRpb24uCjQuIHJlbW92 YWwgb2YgdW5kZXNpcmVkICNpZmRlZi4uLiNlbmRpZiBzdGF0ZW1lbnRzIAo1LiBOb3RlOiBYRl9W RVJTSU9OIHdhcyBub3QgYWR2YW5jZWQuIFRoaXMgd2lsbCBoYXBwZW4gaW4gdGhlIG5leHQgcGF0
...
I tend to reply:
Please do not send base 64 encoded messages. Please do not send HTML messages. Please send plain text only. Message unreadable, ignored. Sorry.
Technically, you write: "function_no is defined by the enum type of _exports.h, so it must be included in the stand alone program."
I willreject this patch. As the name "_exports.h" suggests, it is intended to contain implementation internals that are not supposed to be used by application code.
Also, please assume that "_exports.h" is under GPL...
Best regards,
Wolfgang Denk
Technically, you write: "function_no is defined by the enum type of _exports.h, so it must be included in the stand alone program."
I willreject this patch. As the name "_exports.h" suggests, it is intended to contain implementation internals that are not supposed to be used by application code.
Let me clearify (then I can update the doucmentation if we come up with a better description). As you know, the list of functions in _exports.h is used to create the enumerated type: XF_get_version 0, XF_getc 1, XF_tstc 2, ... Etc. So as long as the user has included exports.h or has uses some other means to identify the function's jump table inxex number in his/her stand along program, he can know if that function is available in u-boot.
This is useful when, for exmaple, a company builds boards both with and without NAND support. A stand along program will be able to know that that board was loaded with a u-boot that did not incude NAND support.
Also, please assume that "_exports.h" is under GPL...
I thought it got used by exports.h to "define interfaces to U-Boot." thought these files are not listed below, wouldn't it be necessary to use these in order to decode the jump table? I do not mean to open up the licensing can of worms again, but knowing XF_foobar enumerated values are necessary to use the jump table, right?
From COPPYING file:
"NOTE! This copyright does *not* cover the so-called "standalone" applications that use U-Boot services by means of the jump table provided by U-Boot exactly for this purpose - this is merely considered normal use of U-Boot, and does *not* fall under the heading of "derived work".
The header files 'include/image.h' and 'include/asm-*/u-boot.h' define interfaces to U-Boot. Including these (unmodified) header files in another file is considered normal use of U-Boot, and does *not* fall under the heading of 'derived work'."
-JM
Jeff Mann wrote:
Technically, you write: "function_no is defined by the enum type of _exports.h, so it must be included in the stand alone program."
I will reject this patch. As the name "_exports.h" suggests, it is intended to contain implementation internals that are not supposed to be used by application code.
Let me clearify (then I can update the doucmentation if we come up with a better description). As you know, the list of functions in _exports.h is used to create the enumerated type: XF_get_version 0, XF_getc 1, XF_tstc 2, ... Etc. So as long as the user has included exports.h or has uses some other means to identify the function's jump table inxex number in his/her stand along program, he can know if that function is available in u-boot.
This is useful when, for exmaple, a company builds boards both with and without NAND support. A stand along program will be able to know that that board was loaded with a u-boot that did not incude NAND support.
[snip]
-JM
What would be Really Cool[tm] would be to enhance the elf loading capability to resolve unresolved link addresses for the standalone application entry points. Then the standalone program could be loaded by u-boot with the interfaces fixed up by the elf loader. This would eliminate all the problems of jump tables and keeping them synchronized.
http://www.gnu.org/software/binutils/manual/html_chapter/binutils_14.html http://www.linuxjournal.com/article/1059 http://www.linuxjournal.com/article/1060
Possible problems that come to mind... * Code bloat * The coupling between GPL u-boot and potentially proprietary standalone programs arguably is tighter. In practical terms, I don't see this as an issue, but it really isn't my call. I would contend this is similar to linux loadable device drivers and the current standalone programs have license to call back into u-boot - the same functions, simply a different interface mechanism. * My ignorance may be making a molehill out of a mountain of work * So many interesting things to do, so little time :-(
Best regards, gvb
What would be Really Cool[tm]
My idea was simply this (better with an example)
STAND ALONE PROGRAM ... #include exports.h ... char *argv[4] = { "nand", "device", "1", NULL }
/* select NAND device 1 */ if (!(xf_func_inc(XF_do_nand))){ /* make sure that this u-boot has nand support */ if(do_nand (0, 0, 3,argv)) puts("nand device 1 selected"); } Else { puts("Nand not supported"); }
This was a better solution than simply letting the dummy function catch it.
-JM
Jeff Mann wrote:
Patch did not attach. Let me try again...
[PATCH] Update to stand alone program feature
This patch contains updates to the stand alone program feature, including:
- update and document new features in README.standalone 2.
Jeff,
when you are at updating README.standalone, there's one notice I think would be worthwile to add as a precaution for external apps utilizing U-Boot: the code of the jumptable consumer should pay attention not to use U-Boot-dedicated registers (like r29 etc.) in order to safely go forth and back, or save/restore. This can bite for example when an external app code is built -O2 or higher and registers are used intensively. Would you care to add such a note along with your updates?
kind regards, Rafal
participants (4)
-
Jeff Mann -
Jerry Van Baren -
Rafal Jaworowski -
Wolfgang Denk