Blackfin: implement go/boote wrappers
PATCH 1/1 Blackfin: implement go/boote wrappers
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).
---
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%)lib_blackfin/Makefile +1 -1
@@ -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
lib_blackfin/boot.c renamed from lib_blackfin/bootm.c +20 -0
@@ -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); +}
Signature · 1 line
1.5.5
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 3 lines · In message <[email protected]> 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
Signature · 7 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 10 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> 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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 5 lines
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
Signature · 6 lines
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_
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 6 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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".
Quoted 8 lines
Quoted 3 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 3 lines
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
Signature · 6 lines
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.PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 11 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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
Signature · 4 lines
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!
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 12 lines · Wolfgang Denk
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 4 lines
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 ... ]Quoted 6 lines
Quoted 3 lines
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
Signature · 5 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 10 lines · Wolfgang Denk
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 6 lines
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".
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 13 lines · Mike Frysinger
Quoted 6 lines · Wolfgang Denk
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).
Quoted 4 lines
so we can do:
go [-noret] addr [args...]or we can add "jump" to
cmd_boot.cand 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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
or we can add "jump" to
cmd_boot.cand 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
Signature · 5 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
In reply to Mike FrysingerQuoted 6 lines · In message <[email protected]> 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".
Quoted 4 lines
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
or we can add "jump" to
cmd_boot.cand 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.
Quoted 4 lines
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
Signature · 6 lines
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.PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 9 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 1 line
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.
Quoted 13 lines
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
Quoted 2 lines
or we can add "jump" to
cmd_boot.cand 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.
Quoted 8 lines
Quoted 4 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Signature · 6 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 7 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 2 lines
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.
Quoted 7 lines
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>
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
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. ?
Quoted 8 lines
Quoted 2 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 6 lines
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.
Quoted 1 line
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".
Quoted 3 lines
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?
Quoted 2 lines
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.
Quoted 2 lines
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
Signature · 5 lines
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
PATCH 1/1 Blackfin: implement go/boote wrappers
Quoted 7 lines · Wolfgang Denk
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 5 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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