[U-Boot-Users] "go addr" Question...

[U-Boot-Users] "go addr" Question...

[Robin Getz]

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

[U-Boot-Users] "go addr" Question...

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any sufficiently advanced  technology  is  indistinguishable  from  a
rigged demo.                              - Andy Finkel, computer guy

[U-Boot-Users] Re: "go addr" Question...

[Robin Getz]

>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 

[U-Boot-Users] Re: "go addr" Question...

[Robin Getz]

>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 

[U-Boot-Users] Re: "go addr" Question...

[Jerry Van Baren]

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

[U-Boot-Users] Re: "go addr" Question...

[Robin Getz]

>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

This is how we have things set up (data cache and instruction cache on by 
default).

Based on the fact that uncompressing an image :

icache   dcache  time boot*
  off       off   11 seconds
  off        on   10 seconds
   on       off    3 seconds
   on        on    1 second

*time to boot is based on the time to bootm to check the checksum, and 
uncompress the image, and print out "Starting Kernel at 0xnnnnnn".

Our customers want sub 2 second boot time - so we need to have both dcache 
and icache on.

If the restriction is that you can't use the go command with dcache on, 
then I can also live with that (and just put 'dcache on;' as part of the 
boot command for Linux kernels.

-Robin

[U-Boot-Users] Re: "go addr" Question...

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is not best to swap horses while crossing the river.
- Abraham Lincoln

[U-Boot-Users] Re: "go addr" Question...

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It took him several minutes to understand any new idea  put  to  him,
and  this is a very valuable trait in a leader, because anything any-
one is still trying to explain to you after two minutes  is  probably
important  and anything they give up after a mere minute or so is al-
most certainly something they shouldn't have been bothering you  with
in the first place.                   - Terry Pratchett, _Reaper Man_

[U-Boot-Users] Re: "go addr" Question...

[Wolfgang Denk]

In message <6.1.1.1.0.20050906134835.01ebd8a0@ptg1.spd.analog.com> you wrote:
> 
> If the restriction is that you can't use the go command with dcache on, 

Ther4e is no such restriction, at least not intentionally. If this is
the case on your system, there must be a bug somewhere  which  should
be fixed.

It's working for me, both on systems with dcache  off  (like  8xx  or
8260) and on (like 8240).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Only a fool fights in a burning house.
	-- Kank the Klingon, "Day of the Dove", stardate unknown

[U-Boot-Users] Re: "go addr" Question...

[Scott McNutt]

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

[U-Boot-Users] Re: "go addr" Question...

[Robin Getz]

Just an update - We found out what the issue was - the application in 
question assumed caches were off when it started, and re-initialized things 
without flushing things, which the hardware didn't like. Since this doesn't 
seem like a generic U-Boot issue - we are just making sure that when 
applications are started - they assume cache can be on or off, and set 
things appropriately.

Thanks for the help.