[U-Boot-Users] "go addr" Question...
We were having an issue with the command "go addr" starting some binary images (like the linux kernel and others).
Aubrey Li tracked this down to what appears to us as an issue in u-boot/common/cmd_boot.c:do_go which doesn't clear, or invalidate cache.
Right now, we added this to our cvs, with an ifdef - if this is a common need for other architectures, we can take out the ifdef, and re-sumbit the patch.
Comments, Suggestions, or Criticisms welcomed.
Thanks -Robin
diff -u -r1.1.1.1 -r1.2 --- cmd_boot.c 13 Mar 2005 21:26:46 -0000 1.1.1.1 +++ cmd_boot.c 6 Sep 2005 08:05:51 -0000 1.2 @@ -48,6 +48,10 @@
printf ("## Starting application at 0x%08lX ...\n", addr);
+#if defined(CONFIG_BLACKFIN) + if(icache_status()) + invalidate_entire_icache(); +#endif
/* * pass address parameter as argv[0] (aka command name), * and all remaining args
In message 6.1.1.1.0.20050906095816.01ebaeb0@ptg1.spd.analog.com you wrote:
We were having an issue with the command "go addr" starting some binary images (like the linux kernel and others).
You are aware that Linux is supposed to be booted using the bootm command, aren't you?
Aubrey Li tracked this down to what appears to us as an issue in u-boot/common/cmd_boot.c:do_go which doesn't clear, or invalidate cache.
Why do you think this is a problem? Caches are flushed after loading an image.
Right now, we added this to our cvs, with an ifdef - if this is a common need for other architectures, we can take out the ifdef, and re-sumbit the patch.
It will be rejected...
+#if defined(CONFIG_BLACKFIN)
if(icache_status())invalidate_entire_icache();+#endif
This will just cause linker errors. There is no function invalidate_entire_icache() anywhere in U-Boot.
Best regards,
Wolfgang Denk
You are aware that Linux is supposed to be booted using the bootm command, aren't you?
Yes - The kernel image was just one of many applications that was causing problems. Normally we boot the kernel image with bootm.
Why do you think this is a problem? Caches are flushed after loading an image.
If the image is loaded with bootm - yes, but if a binary image is loaded directly with tftp or loadb - the cache is not flushed.
This will just cause linker errors. There is no function invalidate_entire_icache() anywhere in U-Boot.
My bad - sorry. This is something that we added to our cache handler. I can put in the generic routine but only if you agree there is a problem - otherwise I will just tell people they shouldn't use go for anything other than U-Boot stand-alone applications.
-Robin
It is gets flushed with loads: and with loadb: and with all network commands (tftp, nfs):
Ok - maybe I am missing something - do you expect U-Boot to be cached? i.e. the polling of the serial line - if that is in cache when someone says "go" - where is that flushed?
Thanks -Robin
Robin Getz wrote:
It is gets flushed with loads: and with loadb: and with all network commands (tftp, nfs):
Ok - maybe I am missing something - do you expect U-Boot to be cached? i.e. the polling of the serial line - if that is in cache when someone says "go" - where is that flushed?
Thanks -Robin
I'm probably setting myself up for being slapped down since there are so many targets that a generalization is generally wrong :-) but...
U-boot typically runs with instruction cache enabled and data cache disabled (experience base: PowerPC). This is because instruction cache "just works" and is very beneficial and data cache generally causes massive grief (it is pretty much useless without setting up the BATs or full MMU on the PowerPC).
It sounds like Robin has data caching turned on, which would explain why he needs to flush the data cache before jumping to his newly loaded executable. If data caching is turned off, this would not be a problem because you would not have been executing where the new code is loaded in (unless you are doing something really weird), therefore it would not have stale instructions in the instruction cache.
gvb
In message 431DD0C1.6040707@smiths-aerospace.com you wrote:
U-boot typically runs with instruction cache enabled and data cache disabled (experience base: PowerPC). This is because instruction cache
We typically enable icache, that's true. If data cache is on or off depends, even on PowerPC. See the README.
"just works" and is very beneficial and data cache generally causes massive grief (it is pretty much useless without setting up the BATs or full MMU on the PowerPC).
Data cache can be very important if you need an initial stack before you have any writable memory on the system.
It sounds like Robin has data caching turned on, which would explain why he needs to flush the data cache before jumping to his newly loaded
No, it does not. As I just explained, all download commands implement cache flushing (I think).
Best regards,
Wolfgang Denk
Hi All,
Jerry Van Baren wrote:
executable. If data caching is turned off, this would not be a problem
Agreed. Unfortunately, on some architectures you can't disable the data cache. I have _similar_ issues with Nios-II bootm since the dcache is not flushed after a gzipped kernel is decompressed: http://sourceforge.net/mailarchive/message.php?msg_id=11245412
However, I don't have any problems with download and go commands. The dcache is already flushed as required.
Regards, --Scott
In message 6.1.1.1.0.20050906130344.01ec0300@ptg1.spd.analog.com you wrote:
Ok - maybe I am missing something - do you expect U-Boot to be cached? i.e.
I can't parse that. The decision if icache and/or dcache are turned on depent on the hardare and the implementation; see the README.
the polling of the serial line - if that is in cache when someone says "go"
- where is that flushed?
I can't parse that either. What is "that", please? I just explained to you that after a serial doenload (using loads or lobd commands) the area where the downloaded code was stored gets flushed.
Best regards,
Wolfgang Denk
participants (4)
-
Jerry Van Baren -
Robin Getz -
Scott McNutt -
Wolfgang Denk