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...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stand_alone_prog.patch
Type: application/octet-stream
Size: 6051 bytes
Desc: stand_alone_prog.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070509/52183f4d/attachment.obj

...

...

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

DENX Software Engineering GmbH,    CEO: 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 at denx.de
The Wright Bothers weren't the first to fly. They were just the first
not to crash.

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.

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

[snip]

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

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,

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