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

[Mitch D. <mj...@al...>]

NIIBE Yutaka wrote:
> 
> Mitch Davis wrote:
>  > As Greg indicated in his earlier email, here are the diffs we
>  > have been working on.  There's a patch for the kernel code, and
>  > a patch for the stub.
> 
>  > x  Link script sets Load Memory Addresses so that kernel image
>  >    load bypasses the cache, to avoid cache problems.
> 
> No, this is backward.  If you have any problems, please send us bug
> report.  The changes like this just paper the bugs, and hide them.
> It's not the solution.  Major problem is it loses performance.
> Besides, I don't know the problem around cache issues, which is
> solved with this change.

Hi Niibe-san,

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.

Running the kernel in the P2 area would surely compromise 
performance, and would indeed be a bad fix for a cache-related
problem! :-)

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.

> It seems for me that what to change is GDB stub, if needed.

It would be possible to change the stub so it has explicit code
to flush the cache after a transfer.  But the stub does not
know whether gdb on the host is sending a program, or setting
a variable.  Should it flush the whole cache every time
a variable is set?  Is it safe to do so without the kernel
knowing?  And also, the details of flushing the cache
are rather processor-specific, something it would be best to
keep out of the stub.

The other solution would be for the stub to mask incoming data so
they fall in the P2 area.  But I think this will not only 
mislead people, but may cause cache consistency problems
half-way through the run, because the variable is set past the
cached copy.

IMO, changing the Linux link file is a better way of determining
how the stub puts a loaded program into memory, and it avoids
these other problems.

Yes, storing into P2 will be a little slower than storing into
P1, but I believe the delay in waiting for data from a serial port
will be several orders of magnitude slower, so there won't be
any noticeable performance hit when loading the kernel.  (And
as I mentioned, none when running it).

Well, that's how we've been looking at it, but I'm only a beginner
with these things.  What do you think?  Would you prefer to see the
problem solved in another way?  Is there some issue which will
bite us with this approach, which we are not seeing?

I look forward to hearing your opinion.

Regards,

Mitch.
--
mailto:mj...@al... | Certified Linux Evangelist!