Re: [linuxsh-dev] Assorted patches for Linux kernel, and the stub.

[NIIBE Y. <gn...@ch...>]

Mitch Davis wrote:
 > Please note that it is NOT the purpose of this patch to run the
 > kernel in the uncached P2 area (A0000000) - with this patch, the
 > kernel is still linked against and will still run in the cached
 > P1 area (80000000).  This patch only changes where the kernel is
 > loaded by a stub.
[...]
 > The problem we have faced a number of times was that kernel
 > downloading was not successful - even small programs would sometimes
 > not load properly.  (I had this problem at HP too, but not
 > involving Linux or our toolchain).  We traced this to the bootloader
 > not flushing the cache after the load.
 > 
 > As you know, using the "AT" linker directive makes it possible
 > link a program to run at a certain address (in this case, 80000000)
 > but be loaded at another address.  (In this case, A0000000).
 > Doing this ALWAYS fixed our problems.

OK, I didn't understand the issues, now have understood.  I don't
understand stub hits this problem, as it disables caches.

If there's problem, it's the bug of stub, I think.

I think that what you should change is the loader (stub or other).
Yes, you can work around the problem with this patch, but I don't
think this is solution.  If I were at the problem, I fix the loader so
that it flush the cache at the point needed.  For GDB stub (with cache
enabled), the point would be continue command handling where we need
to flush data cache so that instruction loaded from memory works fine.

 > And also, the details of flushing the cache are rather
 > processor-specific, something it would be best to keep out of the
 > stub.

Please look at the code, it already has the cache flushing code, as
breakpoints need this.

My point is: kernel image (vmlinux) is not just for the environment of
GDB stub (with cache enabled).  It could be used as other loader, used
by building zImage, or used when we wrote it into Flash ROM.  I think
that it's better not introducing other artifact here.
--