[U-Boot-Users] [PATCH] Update to stand alone program feature

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Jeff Mann]

[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

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Jeff 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:
> 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
> 
-------------- 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 

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Wolfgang Denk]

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

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

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Jeff Mann]

> 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

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Rafal Jaworowski]

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

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Jerry Van Baren]

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

[U-Boot-Users] [PATCH] Update to stand alone program feature

[Jeff Mann]

 
> 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