[U-Boot] Modify go to allow chain loading a second u-boot
Hi,
for all the wrong reasons I have to load a second u-boot from a first one.
I'm finally able to start it, but it only works if I do a cleanup_before_linux(), i.e. turn off interrupts and caches before the actual 'go'.
For testing I patched the go command, but obviously this can't be contributed as such.
Anyone having a suggestion on how to do this?
1) add option to 'go' command, which is hard as it has variable arguments 2) add another go command 3) use an environment variable to set the option for 'go'
Theoretically I could use an u-boot image to encapsulate the second u-boot and use 'bootm', but I think I'll stumble over the same kind of questions.
Helmut PS: this is a re-post (the original one hung on-to the thread where I asked for help in the first place).
-- Scanned by MailScanner.
Hi,
On 3 April 2014 03:40, Helmut Raiger helmut.raiger@hale.at wrote:
Hi,
for all the wrong reasons I have to load a second u-boot from a first one.
I'm finally able to start it, but it only works if I do a cleanup_before_linux(), i.e. turn off interrupts and caches before the actual 'go'.
For testing I patched the go command, but obviously this can't be contributed as such.
Anyone having a suggestion on how to do this?
- add option to 'go' command, which is hard as it has variable arguments
This seems best to me if you don't want to add a new command. Maybe you could add a '-c' argument to cleanup?
- add another go command
- use an environment variable to set the option for 'go'
Theoretically I could use an u-boot image to encapsulate the second u-boot and use 'bootm', but I think I'll stumble over the same kind of questions.
Helmut PS: this is a re-post (the original one hung on-to the thread where I asked for help in the first place).
Regards, Simon
On 04/08/2014 04:27 AM, Simon Glass wrote:
1) add option to 'go' command, which is hard as it has variable argumentsThis seems best to me if you don't want to add a new command. Maybe you could add a '-c' argument to cleanup?
This kind of option is clearly not what other u-boot commands use, I could not find a single command that supports '-' style options. If this had been widely used, I wouldn't have asked in the first place.
Thanks anyway, answers are flowing in quite sparsely.
Helmut
-- Scanned by MailScanner.
Dear Helmut,
In message 53455133.5010200@hale.at you wrote:
This seems best to me if you don't want to add a new command. Maybe you could add a '-c' argument to cleanup?
This kind of option is clearly not what other u-boot commands use, I could not find a single command that supports '-' style options. If this had been widely used, I wouldn't have asked in the first place.
It seems you did not look very carefully. Just for example:
=> help env env - environment handling commands
Usage: env ask name [message] [size] - ask for environment variable env default [-f] -a - [forcibly] reset default environment env default [-f] var [...] - [forcibly] reset variable(s) to their default values env delete [-f] var [...] - [forcibly] delete variable(s) env edit name - edit environment variable env export [-t | -b | -c] [-s size] addr [var ...] - export environment env import [-d] [-t | -b | -c] addr [size] - import environment env print [-a | name ...] - print environment env run var [...] - run commands in an environment variable env save - save environment env set [-f] name [arg ...]
Best regards,
Wolfgang Denk
This kind of option is clearly not what other u-boot commands use, I could not find a single command that supports '-' style options. If this had been widely used, I wouldn't have asked in the first place.
It seems you did not look very carefully. Just for example:
=> help env env - environment handling commands
Yes it seems ;-)
Thx, I'll look into that. Helmut
-- Scanned by MailScanner.
On Thu, Apr 3, 2014 at 4:40 AM, Helmut Raiger helmut.raiger@hale.at wrote:
Hi,
for all the wrong reasons I have to load a second u-boot from a first one.
FYI, I can do this without problems on highbank. It's certainly useful for development.
I'm finally able to start it, but it only works if I do a cleanup_before_linux(), i.e. turn off interrupts and caches before the actual 'go'.
Most platforms (at least on ARM) don't enable interrupts, so your problem is probably the cache. Loaded data (2nd u-boot) goes into the d-cache and needs to be flushed to be in sync with the i-cache on Harvard architecture processors. It works for me since the d-cache is not enabled in u-boot on highbank (and all the init code is safe to run twice).
For testing I patched the go command, but obviously this can't be contributed as such.
Anyone having a suggestion on how to do this?
The go command should have a defined state with respect to caches as to how programs are entered. Loading code and jumping to it without any cache maintenance is simply broken. Fix the go command. If an architecture does not need a cache flush, then it should simply be a nop.
Rob
participants (4)
-
Helmut Raiger -
Rob Herring -
Simon Glass -
Wolfgang Denk