[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

Override the default go/boote handlers as we want to disable both data and
instruction cache before executing external programs (since Blackfin cache
handling requires a software handler in U-Boot which may be overwritten).

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 lib_blackfin/Makefile            |    2 +-
 lib_blackfin/{bootm.c => boot.c} |   20 ++++++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletions(-)
 rename lib_blackfin/{bootm.c => boot.c} (80%)

diff --git a/lib_blackfin/Makefile b/lib_blackfin/Makefile
index 3617104..879c37f 100644
--- a/lib_blackfin/Makefile
+++ b/lib_blackfin/Makefile
@@ -37,7 +37,7 @@ SOBJS-y	+= memmove.o
 SOBJS-y	+= memset.o
 
 COBJS-y	+= board.o
-COBJS-y	+= bootm.o
+COBJS-y	+= boot.o
 COBJS-y	+= cache.o
 COBJS-y	+= muldi3.o
 COBJS-y	+= post.o
diff --git a/lib_blackfin/bootm.c b/lib_blackfin/boot.c
similarity index 80%
rename from lib_blackfin/bootm.c
rename to lib_blackfin/boot.c
index ef4b112..5ea4afb 100644
--- a/lib_blackfin/bootm.c
+++ b/lib_blackfin/boot.c
@@ -77,3 +77,23 @@ void do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 	if (images->autostart)
 		do_reset (cmdtp, flag, argc, argv);
 }
+
+unsigned long do_go_exec(ulong (*entry)(int, char *[]), int argc, char *argv[])
+{
+	int d = dcache_status();
+	int i = icache_status();
+
+	dcache_disable();
+	icache_disable();
+
+	int ret = entry(argc, argv);
+
+	if (d) dcache_enable();
+	if (i) icache_enable();
+
+	return ret;
+}
+unsigned long do_bootelf_exec(ulong (*entry)(int, char *[]), int argc, char *argv[])
+{
+	return do_go_exec(entry, argc, argv);
+}
-- 
1.5.5

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <1208583950-9454-1-git-send-email-vapier@gentoo.org> you wrote:
> Override the default go/boote handlers as we want to disable both data and
> instruction cache before executing external programs (since Blackfin cache
> handling requires a software handler in U-Boot which may be overwritten).

Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
not overwrite (or otherwise meddle with) any U-Boot code.

I think you should not change cache status for "go".

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 at denx.de
... The things love can drive a man to -- the  ecstasies,  the  mise-
ries,  the broken rules, the desperate chances, the glorious failures
and the glorious victories.
	-- McCoy, "Requiem for Methuselah", stardate 5843.7

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Sunday 20 April 2008, Wolfgang Denk wrote:
> In message <1208583950-9454-1-git-send-email-vapier@gentoo.org> you wrote:
> > Override the default go/boote handlers as we want to disable both data
> > and instruction cache before executing external programs (since Blackfin
> > cache handling requires a software handler in U-Boot which may be
> > overwritten).
>
> Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> not overwrite (or otherwise meddle with) any U-Boot code.
>
> I think you should not change cache status for "go".

reality is that people often times use go to execute their binary blobs.  i 
also see it this way: go means to jump to some address and most likely never 
return.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080420/eccf9a97/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804202031.31936.vapier@gentoo.org> you wrote:
> 
> > Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> > not overwrite (or otherwise meddle with) any U-Boot code.
> >
> > I think you should not change cache status for "go".
> 
> reality is that people often times use go to execute their binary blobs.  i
> also see it this way: go means to jump to some address and most likely never 
> return.

This may be your private interpretation, but it is wrong.

Intended and documented behaviour is that "go" is used to start
standalone applications, which are supposed to return.

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 at denx.de
They're usually so busy thinking about what  happens  next  that  the
only  time they ever find out what is happening now is when they come
to look back on it.                 - Terry Pratchett, _Wyrd Sisters_

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804202031.31936.vapier@gentoo.org> you wrote:
> > > Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> > > not overwrite (or otherwise meddle with) any U-Boot code.
> > >
> > > I think you should not change cache status for "go".
> >
> > reality is that people often times use go to execute their binary blobs. 
> > i also see it this way: go means to jump to some address and most likely
> > never return.
>
> This may be your private interpretation, but it is wrong.
>
> Intended and documented behaviour is that "go" is used to start
> standalone applications, which are supposed to return.

then how exactly are people supposed to execute their flat binaries ?  none of 
the other boot methods allow for straight jumps that i'm aware of.  otherwise 
i'm going to have to add even more bloat to add a slight variation on the go 
command: one where the documentation doesnt require it to return.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/ac68d99c/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804210125.45077.vapier@gentoo.org> you wrote:
>
> > Intended and documented behaviour is that "go" is used to start
> > standalone applications, which are supposed to return.
> 
> then how exactly are people supposed to execute their flat binaries ?  none of 

I am not an expert for the Blackfin implementation. But "go"  is  for
standalone applications. The "boot*" commands are intended to boot OS
images.

> the other boot methods allow for straight jumps that i'm aware of.  otherwise 
> i'm going to have to add even more bloat to add a slight variation on the go 
> command: one where the documentation doesnt require it to return.

That makes no sense to me. If you want to boot some OS, use a "boot*"
commands, not "go" or the like.

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 at denx.de
Sometimes a man will tell his bartender things he'll never tell his doctor.
	-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
	   stardate unknown.

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210125.45077.vapier@gentoo.org> you wrote:
> > > Intended and documented behaviour is that "go" is used to start
> > > standalone applications, which are supposed to return.
> >
> > then how exactly are people supposed to execute their flat binaries ? 
> > none of
>
> I am not an expert for the Blackfin implementation. But "go"  is  for
> standalone applications. The "boot*" commands are intended to boot OS
> images.
>
> > the other boot methods allow for straight jumps that i'm aware of. 
> > otherwise i'm going to have to add even more bloat to add a slight
> > variation on the go command: one where the documentation doesnt require
> > it to return.
>
> That makes no sense to me. If you want to boot some OS, use a "boot*"
> commands, not "go" or the like.

i'm not talking about operating system code, i'm talking about flat binary 
applications that run bare metal.  something like "u-boot.bin" where it's 
just a binary blob that gets loaded and u-boot jumps to it and never returns.

since "go" isnt appropriate according to you (and seeing as how none of the 
boot commands are appropriate), then the only next step is to implement 
a "jump" command that is exactly like "go" except it doesnt return.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/ac20f856/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804210349.27495.vapier@gentoo.org> you wrote:
>
> > That makes no sense to me. If you want to boot some OS, use a "boot*"
> > commands, not "go" or the like.
> 
> i'm not talking about operating system code, i'm talking about flat binary
> applications that run bare metal.  something like "u-boot.bin" where it's 
> just a binary blob that gets loaded and u-boot jumps to it and never returns.
> since "go" isnt appropriate according to you (and seeing as how none of the>  
> boot commands are appropriate), then the only next step is to implement 
> a "jump" command that is exactly like "go" except it doesnt return.

This makes no sense. If it is ``exactly like "go"'' it doesn't matter
if the code returns or not (and actually this is what I'm  trying  to
point out all the time).

It's just that "go" shall retain the standard U-Boot environment for
application it runs, and that the applications need to take care if
they need to meddle with interrupts, exception handlers, etc.


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 at denx.de
F u cn rd ths u cnt spl wrth a dm!

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210349.27495.vapier@gentoo.org> you wrote:
> > > That makes no sense to me. If you want to boot some OS, use a "boot*"
> > > commands, not "go" or the like.
> >
> > i'm not talking about operating system code, i'm talking about flat
> > binary applications that run bare metal.  something like "u-boot.bin"
> > where it's just a binary blob that gets loaded and u-boot jumps to it and
> > never returns. since "go" isnt appropriate according to you (and seeing
> > as how none of the> boot commands are appropriate), then the only next
> > step is to implement a "jump" command that is exactly like "go" except it
> > doesnt return.
>
> This makes no sense. If it is ``exactly like "go"'' it doesn't matter
> if the code returns or not (and actually this is what I'm  trying  to
> point out all the time).

the obvious implication is that i would add the cache disabling hooks to the 
jump command instead of the go command since you wont allow the hook around 
go.

> It's just that "go" shall retain the standard U-Boot environment for
> application it runs, and that the applications need to take care if
> they need to meddle with interrupts, exception handlers, etc.

U-Boot sets up no interrupts and the only exceptions that occur on the 
Blackfin are for cache handling.  disabling the caches forces a sane 
environment where applications dont have to deal with a chicken/egg of having 
to setup exception handlers before taking an exception.  we've seen it 
already with customers.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/1f91120b/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804210541.41085.vapier@gentoo.org> you wrote:
>
> > This makes no sense. If it is ``exactly like "go"'' it doesn't matter
> > if the code returns or not (and actually this is what I'm  trying  to
> > point out all the time).
> 
> the obvious implication is that i would add the cache disabling hooks to the 
> jump command instead of the go command since you wont allow the hook around 
> go.

So it would NOT be ``exactly like "go"''.

Providing both a "go" and a "jump" command which differ just in cahce
handling seems broken to me. If you want to add such a feature,  then
I recommend to do it as part of "go", but make it optional, i. e. in-
troduce a new optional argument to the "go" command, something like

	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]

> > It's just that "go" shall retain the standard U-Boot environment for
> > application it runs, and that the applications need to take care if
> > they need to meddle with interrupts, exception handlers, etc.
> 
> U-Boot sets up no interrupts and the only exceptions that occur on the 
> Blackfin are for cache handling.  disabling the caches forces a sane 

There is more procvessors in  this  world  than  just  Blackfin,  and
others  *do*  enable  interrupts,  etc.  It  is  important to me that
implementations behave the same no matter which architecture you  are
using.


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 at denx.de
Where there's no emotion, there's no motive for violence.
	-- Spock, "Dagger of the Mind", stardate 2715.1

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210541.41085.vapier@gentoo.org> you wrote:
> > > This makes no sense. If it is ``exactly like "go"'' it doesn't matter
> > > if the code returns or not (and actually this is what I'm  trying  to
> > > point out all the time).
> >
> > the obvious implication is that i would add the cache disabling hooks to
> > the jump command instead of the go command since you wont allow the hook
> > around go.
>
> So it would NOT be ``exactly like "go"''.

well, duh.  my point was that you're making "go" get duplicated just to 
conform to documentation.  the command name itself "go" doesnt really conjurn 
up usage of "executing an application and returning" ... fits better with "go 
to this location and never come back".  "run" probably would have been a 
better name.  but that's hindsight for you.

> Providing both a "go" and a "jump" command which differ just in cahce
> handling seems broken to me. If you want to add such a feature,  then
> I recommend to do it as part of "go", but make it optional, i. e. in-
> troduce a new optional argument to the "go" command, something like
>
> 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]

cache is just an example.  other arches may want to do other sort of "system 
breakdown/cleanup" before relinquishing control.  option flags to commands 
really doesnt fit the style of u-boot (i expect that sort of painful option 
parsing in redboot, not really u-boot).

so we can do:
	go [-noret] addr [args...]
or we can add "jump" to cmd_boot.c and merge the differences by just using a 
function pointer to "do_go_exec" or "do_jump_exec".

> > > It's just that "go" shall retain the standard U-Boot environment for
> > > application it runs, and that the applications need to take care if
> > > they need to meddle with interrupts, exception handlers, etc.
> >
> > U-Boot sets up no interrupts and the only exceptions that occur on the
> > Blackfin are for cache handling.  disabling the caches forces a sane
>
> There is more procvessors in  this  world  than  just  Blackfin,  and
> others  *do*  enable  interrupts,  etc.  It  is  important to me that
> implementations behave the same no matter which architecture you  are
> using.

i never said Blackfin was the only thing that mattered.  in fact, my goal is 
to make it so that people using this facility get a more standard initial 
environment before they start taking over the system.  i guess i wont point 
out the U-Boot policy about not using interrupts ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/ce750ff8/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Mike Frysinger wrote:
> On Monday 21 April 2008, Wolfgang Denk wrote:
> > Providing both a "go" and a "jump" command which differ just in cahce
> > handling seems broken to me. If you want to add such a feature,  then
> > I recommend to do it as part of "go", but make it optional, i. e. in-
> > troduce a new optional argument to the "go" command, something like
> >
> > 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]
>
> cache is just an example.  other arches may want to do other sort of
> "system breakdown/cleanup" before relinquishing control.  option flags to
> commands really doesnt fit the style of u-boot (i expect that sort of
> painful option parsing in redboot, not really u-boot).
>
> so we can do:
> 	go [-noret] addr [args...]
> or we can add "jump" to cmd_boot.c and merge the differences by just using
> a function pointer to "do_go_exec" or "do_jump_exec".

untested poc attached
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/edee92fc/attachment.pgp 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-jump-cmd.patch
Type: text/x-diff
Size: 1779 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/edee92fc/attachment.patch 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804210635.08416.vapier@gentoo.org> you wrote:
>
> well, duh.  my point was that you're making "go" get duplicated just to 
> conform to documentation.  the command name itself "go" doesnt really conjurn 
> up usage of "executing an application and returning" ... fits better with "go 
> to this location and never come back".  "run" probably would have been a 
> better name.  but that's hindsight for you.

You are right. Today I would probably name this "call".

> > 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]
> 
> cache is just an example.  other arches may want to do other sort of "system 
> breakdown/cleanup" before relinquishing control.  option flags to commands

As the situation is, other arches seem to be just fine  as  it.  It's
only BF which needs a pork sausage.

> really doesnt fit the style of u-boot (i expect that sort of painful option
> parsing in redboot, not really u-boot).

I don;t like it either, but just ading random new commands is even
worse.

> so we can do:
> 	go [-noret] addr [args...]

Ummm... "no return" programs is just an example.  Other  pograms  may
want  to  do  other  sort of "system breakdown/cleanup" before relin-
quishing control.

> or we can add "jump" to cmd_boot.c and merge the differences by just using > a 
> function pointer to "do_go_exec" or "do_jump_exec".

Adn then we add "call" and "exec" and "do" and so oon just for  other
needed options? I say no.

> i never said Blackfin was the only thing that mattered.  in fact, my goal is 
> to make it so that people using this facility get a more standard initial 
> environment before they start taking over the system.  i guess i wont point
> out the U-Boot policy about not using interrupts ...

Are you aware that U-Boot does use interrupts here and there? That we
actually  provide  functions  to  register  interrupt   handlers   to
standalone programs, etc. ?

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 at denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804210659.43481.vapier@gentoo.org> you wrote:
>
> > or we can add "jump" to cmd_boot.c and merge the differences by just using
> > a function pointer to "do_go_exec" or "do_jump_exec".
> 
> untested poc attached

Don't waste efforts on this. I will not accept it.


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 at denx.de
In the realm of scientific observation, luck is granted only to those
who are prepared.                                     - Louis Pasteur

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210635.08416.vapier@gentoo.org> you wrote:
> > > 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]
> >
> > cache is just an example.  other arches may want to do other sort of
> > "system breakdown/cleanup" before relinquishing control.  option flags to
> > commands
>
> As the situation is, other arches seem to be just fine  as  it.  It's
> only BF which needs a pork sausage.

this is incorrect.  any architecture which wants to overwrite u-boot sanely 
needs to worry about causing exceptions or interrupts.  i just want to make 
the obvious easy since it has caused more than enough support requests.

> > really doesnt fit the style of u-boot (i expect that sort of painful
> > option parsing in redboot, not really u-boot).
>
> I don;t like it either, but just ading random new commands is even
> worse.
>
> > so we can do:
> > 	go [-noret] addr [args...]
>
> Ummm... "no return" programs is just an example.  Other  pograms  may
> want  to  do  other  sort of "system breakdown/cleanup" before relin-
> quishing control.
>
> > or we can add "jump" to cmd_boot.c and merge the differences by just
> > using > a function pointer to "do_go_exec" or "do_jump_exec".
>
> Adn then we add "call" and "exec" and "do" and so oon just for  other
> needed options? I say no.

then implement whatever.  in the mean time i'll keep forking the Blackfin 
code.

> > i never said Blackfin was the only thing that mattered.  in fact, my goal
> > is to make it so that people using this facility get a more standard
> > initial environment before they start taking over the system.  i guess i
> > wont point out the U-Boot policy about not using interrupts ...
>
> Are you aware that U-Boot does use interrupts here and there? That we
> actually  provide  functions  to  register  interrupt   handlers   to
> standalone programs, etc. ?

yes i'm aware, but we arent talking about standalone applications here, so 
those really dont matter.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/902f64c9/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804211444.43917.vapier@gentoo.org> you wrote:
>
> > Adn then we add "call" and "exec" and "do" and so oon just for  other
> > needed options? I say no.
> 
> then implement whatever.  in the mean time i'll keep forking the Blackfin 
> code.

OK. I offered you a way out. It's your decision.

I tried understanding what you are trying to do, and  even  though  I
feel  it's  not  exactly  an important or frequently used feature for
most of the users I tried to come up with a  compromize  that  allows
you  to  do  what  you  want to do without hurting others and without
polluting the command name space.

I'm sorry that I wasted my time on thinking about this.


> > Are you aware that U-Boot does use interrupts here and there? That we
> > actually  provide  functions  to  register  interrupt   handlers   to
> > standalone programs, etc. ?
> 
> yes i'm aware, but we arent talking about standalone applications here, so
> those really dont matter.

You have a really, really funny way of deciding what matters and what
not. All the things you have in mind do  matter  (even  if  they  are
documented to be unsupported), while other existing and legal ways of
doing things don't matter. That doesn't make working with you an easy
task.

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 at denx.de
...the increased productivity fostered by a friendly environment  and
quality  tools  is  essential  to  meet  ever  increasing demands for
software.               - M. D. McIlroy, E. N. Pinson and B. A. Tague

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804211444.43917.vapier@gentoo.org> you wrote:
> > > Adn then we add "call" and "exec" and "do" and so oon just for  other
> > > needed options? I say no.
> >
> > then implement whatever.  in the mean time i'll keep forking the Blackfin
> > code.
>
> OK. I offered you a way out. It's your decision.
>
> I tried understanding what you are trying to do, and  even  though  I
> feel  it's  not  exactly  an important or frequently used feature for
> most of the users I tried to come up with a  compromize  that  allows
> you  to  do  what  you  want to do without hurting others and without
> polluting the command name space.

i consider the cache one aspect of it.  the users shouldnt have to know "oh i 
gotta turn off cache", they just have to know "i'm loading up my code and 
it's going to take over the system".  that is why a "-noret" flags makes 
sense instead of trying to break down specific aspects.  also adding a myriad 
of cache options to one function achieves the same thing as doing:
dcache off; icache off; go <address>

> > > Are you aware that U-Boot does use interrupts here and there? That we
> > > actually  provide  functions  to  register  interrupt   handlers   to
> > > standalone programs, etc. ?
> >
> > yes i'm aware, but we arent talking about standalone applications here,
> > so those really dont matter.
>
> You have a really, really funny way of deciding what matters and what
> not. All the things you have in mind do  matter  (even  if  they  are
> documented to be unsupported), while other existing and legal ways of
> doing things don't matter. That doesn't make working with you an easy
> task.

it's really quite simple.  the need is to jump to an address to execute a blob 
and never return to u-boot.  what features are available to standalone u-boot 
applications (while useful) dont really matter.  such applications rely on 
u-boot remaining resident which is the opposite of what i'm talking about.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/46d3f3e1/attachment.pgp 

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Wolfgang Denk]

In message <200804211658.44036.vapier@gentoo.org> you wrote:
>
> > I tried understanding what you are trying to do, and  even  though  I
> > feel  it's  not  exactly  an important or frequently used feature for
> > most of the users I tried to come up with a  compromize  that  allows
> > you  to  do  what  you  want to do without hurting others and without
> > polluting the command name space.
> 
> i consider the cache one aspect of it.  the users shouldnt have to know "oh i 
> gotta turn off cache", they just have to know "i'm loading up my code and 

I agree that  cache  is  just  one  aspect;  I  disagree  that  users
shouldn't  know what they are doing. On contrary, I want to give them
all necessary control to do what they may want to do. It is a  matter
of higher software levels to provide more convenient abstractions.

> it's going to take over the system".  that is why a "-noret" flags makes 

Who says that *my* application which doesn;t return does the same  as
your  application?  Maybe  I *want* to have the caches on for perfor-
mance?

I accept that the default settings may be not optimal  for  your  use
case,  so please accept that your settings may not be always optimal,
either. As a solution I imagine options to the "go" command.  If  you
consider  this  too  complicated  for your users, please feel free to
provide an alias in an envrionment  variable  which  your  users  can
"run".

> sense instead of trying to break down specific aspects.  also adding a myriad 
> of cache options to one function achieves the same thing as doing:
> dcache off; icache off; go <address>

Ah! You see - there is no need at all for any changes - you can put
*that* sequence in a variable and run it.

So what exactly was the reason we need a new command?

> it's really quite simple.  the need is to jump to an address to execute a blob 
> and never return to u-boot.  what features are available to standalone u-boot 

"go" does that. If your application does not attempt to return, that's
fine.

> applications (while useful) dont really matter.  such applications rely on
> u-boot remaining resident which is the opposite of what i'm talking about.

But then it doesn't hurt, does it? Your application can do anything it
wants as long as it does not attempt to return to U-Boot.


I see zero justification for a  new  command  (and  very  little  for
changes  to  the  implementation  of  "go", but I am still willing to
allow for such  extensions  if  you  think  it's  necessary  or  more
convenient).

I thik this is my last word on this.

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 at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie

[U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers

[Mike Frysinger]

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804211658.44036.vapier@gentoo.org> you wrote:
> > > I tried understanding what you are trying to do, and  even  though  I
> > > feel  it's  not  exactly  an important or frequently used feature for
> > > most of the users I tried to come up with a  compromize  that  allows
> > > you  to  do  what  you  want to do without hurting others and without
> > > polluting the command name space.
> >
> > i consider the cache one aspect of it.  the users shouldnt have to know
> > "oh i gotta turn off cache", they just have to know "i'm loading up my
> > code and
>
> I agree that  cache  is  just  one  aspect;  I  disagree  that  users
> shouldn't  know what they are doing. On contrary, I want to give them
> all necessary control to do what they may want to do. It is a  matter
> of higher software levels to provide more convenient abstractions.

yes, but the fact that we have to turn off caches is not for performance 
reasons.  users should not need to be aware of these system deficiencies 
which is why i'm proposing a "noret" flag.

> > it's going to take over the system".  that is why a "-noret" flags makes
>
> Who says that *my* application which doesn;t return does the same  as
> your  application?  Maybe  I *want* to have the caches on for perfor-
> mance?

i'm not concerned with the performance aspect.  caches on the Blackfin are 
intertwined with protection, and protection handlers require a software 
vector to process exceptions.  the act of executing a program that takes over 
the system means the exception handler is no longer reliable so i have to 
guarantee it wont be called.  based on information given to me from our 
hardware team, this can only be accomplished implicitly by disabling caches.

> I accept that the default settings may be not optimal  for  your  use
> case,  so please accept that your settings may not be always optimal,
> either. As a solution I imagine options to the "go" command.  If  you
> consider  this  too  complicated  for your users, please feel free to
> provide an alias in an envrionment  variable  which  your  users  can
> "run".

i completely accept that the patch i posted to turn off caches for all things 
to "go" result in a suboptimal environment for standalone u-boot 
applications.  for Blackfin usage though, that takes a back seat to things 
silently crashing.

> > applications (while useful) dont really matter.  such applications rely
> > on u-boot remaining resident which is the opposite of what i'm talking
> > about.
>
> But then it doesn't hurt, does it? Your application can do anything it
> wants as long as it does not attempt to return to U-Boot.

except that it may inadvertently do so on Blackfin.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/4e200f81/attachment.pgp