linuxsh-dev

[linuxsh-dev] help for toolchain configuration for fast floating point.

[peter g. <pga...@li...>]

Hi,
   For compact inline floating point, for my sh7750 embedded target platform, I found it necessary to specify -m4 -m4-single to the compiler. I decided to recompile glibc with these switches. Unfortunately this seems to break the second final compilation of gcc, when it is configuring TARGET/libiberty, and the script complains that xgcc will not work. The executable created by xgcc requires the linking of __udivsi3_i4, but in the default toplevel libgcc.a there is only __udivsi3, so my default configuration of gcc has a function mixup.

I am using an overall target configuration of sh-m4-linux-gnu. Despite the m4 there, the compiler default is definitely not m4.
I am compiling glibc with CFLAGS set to -m4 -m4-single, and LDFLAGS set to -m4 as well, in the configparms file. Before i used these switches, the subsequent final gcc build would work.

I suppose the problem must stem from having glibc compiled to a differing default to the compiler, but I need those switches so as to obtain a fast math library. I seek general guidance here. For the record I am using gcc-3.2.2 and glibc 2.3.1. I am strongly tempted to hack gcc/gcc/config/sh/t-sh so that I get only the libraries that I want.

Cheers
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

Re: [linuxsh-dev] mmap caching problem

[peter g. <pga...@li...>]

Hi,
Although I abandoned the shared memory approach to that particular device driver, I would say that the following occurred.

I allocated some memory in a driver and using mmap, passed it to a user space program. An interrupt routine in the driver modified the memory, but changes were not immediately reflected in the memory seen by the user space program, even when the mmap used uncached memory.

I believe that the reason for this was that the kernel driver accessed the memory using a P1 address, which is no address translation, caching on. I think that the SH4 uses different caching for the same memory but with different addresses, in this case user space and P1 area.

I believe that a useful test would have been to try accessing the memory in the kernel driver using the P2 area, by just adding 0x20000000 to the address of the ram. The P2 area is no address translation, no caching. If the kernel driver had no caching, and also user space had no caching, it should have worked.

Instead of using the P2 area, a special SH4 instruction OCBWB to flush the cache at a particular address could also have been used by the kernel driver after modifying the memory area.

I do not know how to specify non-caching for kernel space access in a reasonably portable manner though. The user space memory sets the VM_IO bit in the vm_flags field in the mmap operation. The kernel driver allocates the memory using the call get_zeroed_pages(GFP_KERNEL). I have just tested this call right now and in returns an address at 0x8cea4000, which is in the P1 area, which is cacheable.

So I conclude that all that is necessary is some way to specify non-cacheable memory when allocating pages in a kernel device driver.

  Cheers.
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

Re: [linuxsh-dev] mmap caching problem

[arun4linux <aru...@in...>]

Hello,


I'm also using mmap to export hardware personality to the user/application space.


I'd like to know the exact problem faced by you, how did you detect/proceed to avoid surprise in my solution.


Thanks and Regards


Arun

"peter garrone" wrote:



I ported a device driver that used mmap so that a user space application shared a page with the interrupt routine in a device driver. The mapping software generally followed the "nopage" code outlined in Rubini's book.

I found a caching problem in that the memory contents as seen from the device driver differed to that seen from user space.

At the moment I am changing the design of my driver so that the mapping is unnecessary. I thought I would mention this though before I go to the effort of analying the problem further. 
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
linuxsh-dev mailing list
lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsh-dev

Get Your Private, Free E-mail from Indiatimes at  http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Bid for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now !

Re: [linuxsh-dev] Fixup for the fast SH4 memcpy

[David M. <da...@sn...>]

Jivin Stuart Menefy lays it down ...
> > Attached is a patch,  and the changed original just in case.  I would
> > appreciate any feedback on the correctness/speed implications.  I ran
> > it through an extensive alignment/boundary case test without any problems
> > and it fixed my original crash :-)
> 
> Once I had a test case to throw at it, I fixed it independently, and
> came up with an almost identical fix, a copy of which is
> attached. Either will fix it, and I can't see any correctness
> problems with either.

Sorry to say this but the registers are the wrong way around :-)

The line:

-	cmp/hs	r1, r2		!  58 MT

Needs to be

+	cmp/hs	r2, r1		!  58 MT

My test code showed the problem,  included below for reference, it's
not pretty but it brute force tests memcpy fairly well, it is also way
slow ;-)

Cheers,
Davidm



static unsigned char buffer[256 * 5];
static unsigned char *buf0    = buffer + 256 * 0;
static unsigned char *buf1    = buffer + 256 * 1;
static unsigned char *buf2    = buffer + 256 * 2;
static unsigned char *buf_src = buffer + 256 * 3;

static void memcpy_test()
{
	int i, j, k;
	int c1;

	memset(buf_src, 0xff, 512);
	for (c1 = 0; c1 < 512; c1++)
		buf_src[c1] = (c1 & 0xff);


	for (i = 0; i < 256; i++)
		for (j = 0; j < 256; j++)
			for (k = 0; k + i < 256; k++) {
				memset(buf0, 0x0, 256);
				memset(buf1, 0x0, 256);
				memset(buf2, 0x0, 256);
				memcpy(&buf1[i], &buf_src[j], k);

				for (c1 = 0; c1 < 256; c1++) {
					if (buf0[c1])
						printk("buf0 corrupted at %d (%d,%d,%d)\n",c1,i,j,k);
					if ((c1 < i || c1 >= i + k) && buf1[c1])
						printk("buf1 corrupted at %d (%d,%d,%d)\n",c1,i,j,k);
					if (c1 >= i && c1 < i + k && buf1[c1] != buf_src[j+(c1-i)])
						printk("buf1 not copied   %d (%d,%d,%d,0x%02x)\n",
									c1, i, j, k, buf1[c1]);
					if (buf2[c1])
						printk("buf2 corrupted at %d (%d,%d,%d)\n",c1,i,j,k);
				}
			}
}


-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [linuxsh-dev] Fixup for the fast SH4 memcpy

[David M. <da...@sn...>]

Jivin Stuart Menefy lays it down ...
> Hi David
> 
> On Thu, 27 Feb 2003 17:41:44 +1000 da...@sn... wrote:
> 
> > I found a bug today in the fast SH4 memcpy that Stuart Menefy graciously
> > wrote for us :-).
> 
> All I can say is nuts, and sorry!

No problem,  even with the bug the performance improvements are well
worth the effort and I would rather debug the existing version than
write my own from scratch.  It must have taken a bit of work to get
it going ;-)

> I had a suspicion that there was still a lurking problem, as using
> this memcpy instead of glibc's memcpy caused bash to generate some
> strange errors after a while. However I was never able to pin down the
> circumstances. Before I could investigate further I got diverted onto
> some other work.
> 
> I thought I'd run through all possible tests before releasing this,
> but you found one I'd missed. As soon as I added your size and
> alignments to my test code it spotted it as well. I've now given up on
> testing only selected alignments, and am doing exhaustive tests!

Yeah,  I wrote a quick exhaustive test to check my changes before I
posted them.  Took about 15 minutes to run but was worth it ;-)
I can post a copy if you like.

> > Attached is a patch,  and the changed original just in case.  I would
> > appreciate any feedback on the correctness/speed implications.  I ran
> > it through an extensive alignment/boundary case test without any problems
> > and it fixed my original crash :-)
> 
> Once I had a test case to throw at it, I fixed it independently, and
> came up with an almost identical fix, a copy of which is
> attached. Either will fix it, and I can't see any correctness
> problems with either.
> 
> Performance wise, they are identical: both add one cycle. The only way
> I can see of avoiding the extra test is to use the byte at a time copy
> for remaining lengths 4 to 7.  Best case (4 bytes left) this would
> increase the time from 12 cycles to 19, so I don't think its worth it
> to save one cycle in the 8 to 31 case, which will take a minimum of
> 15 cycles anyway (timings from the 1: label to ret instr).

Cool,  I'll use you version so I am in sync with what you have.  Also I
think the cmp is easier to understand when reading the code ;-)

> So thank you for all the hard work you must have put in tracking this
> down, and sorry again.

No need to be sorry :-)

Thanks,
Davidm

-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [linuxsh-dev] Fixup for the fast SH4 memcpy

[Stuart M. <stu...@st...>]

Hi David

On Thu, 27 Feb 2003 17:41:44 +1000 da...@sn... wrote:

> I found a bug today in the fast SH4 memcpy that Stuart Menefy graciously
> wrote for us :-).

All I can say is nuts, and sorry!

I had a suspicion that there was still a lurking problem, as using
this memcpy instead of glibc's memcpy caused bash to generate some
strange errors after a while. However I was never able to pin down the
circumstances. Before I could investigate further I got diverted onto
some other work.

I thought I'd run through all possible tests before releasing this,
but you found one I'd missed. As soon as I added your size and
alignments to my test code it spotted it as well. I've now given up on
testing only selected alignments, and am doing exhaustive tests!

> Attached is a patch,  and the changed original just in case.  I would
> appreciate any feedback on the correctness/speed implications.  I ran
> it through an extensive alignment/boundary case test without any problems
> and it fixed my original crash :-)

Once I had a test case to throw at it, I fixed it independently, and
came up with an almost identical fix, a copy of which is
attached. Either will fix it, and I can't see any correctness
problems with either.

Performance wise, they are identical: both add one cycle. The only way
I can see of avoiding the extra test is to use the byte at a time copy
for remaining lengths 4 to 7.  Best case (4 bytes left) this would
increase the time from 12 cycles to 19, so I don't think its worth it
to save one cycle in the 8 to 31 case, which will take a minimum of
15 cycles anyway (timings from the 1: label to ret instr).

So thank you for all the hard work you must have put in tracking this
down, and sorry again.

Stuart

[linuxsh-dev] Fixup for the fast SH4 memcpy

[David M. <da...@sn...>]

Hi all,

I found a bug today in the fast SH4 memcpy that Stuart Menefy graciously
wrote for us :-).

Under some situations it was running off the front of the destination buffer
and trashing things.  The case I found was running off the front of the
destination by 8 bytes:

	memcpy(0x881f7cdc, aligned-src, 64)

Attached is a patch,  and the changed original just in case.  I would
appreciate any feedback on the correctness/speed implications.  I ran
it through an extensive alignment/boundary case test without any problems
and it fixed my original crash :-)

Cheers,
Davidm


-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

[linuxsh-dev] mmap caching problem

[peter g. <pga...@li...>]

I ported a device driver that used mmap so that a user space application shared a page with the interrupt routine in a device driver. The mapping software generally followed the "nopage" code  outlined in Rubini's book.

I found a caching problem in that the memory contents as seen from the device driver differed to that seen from user space.

At the moment I am changing the design of my driver so that the mapping is unnecessary. I thought I would mention this though before I go to the effort of analying the problem further. 
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

[linuxsh-dev] Re: compiler problem gcc 3.2 (kaz Kojima)

[peter g. <pga...@li...>]

> Please give it a try with downgrading the optimization to -O1 or
> -O2 -fno-reorder-blocks.

Also "gcc -c -O2 -fno-reorder-blocks prog.c" works.

cheers.
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

[linuxsh-dev] Re: compiler problem gcc 3.2 (kaz Kojima)

[peter g. <pga...@li...>]

Hi,

Thanks very much. I forgot to mention that it fails with -O2 optimization but works with -O1 optimization. That is "gcc -c -O1 prog.c" works, but "gcc -c -O2 prog.c" fails.

-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

[linuxsh-dev] Re: compiler problem gcc 3.2

[kaz K. <kk...@rr...>]

Hi,

"peter garrone" <pga...@li...> wrote:
> The trailing program, derived from the glibc -2.3.1 file
> 
> sysdeps/ieee754/dbl-64/e_atan2.c
> 
> when compiled with gcc 3.2 and also gcc 3.2.2,
> generates this error (gcc 3.2.2).
> gcc is set up as a cross compiler, host linux pc, target sh4.
> 
> prog.c: In function `__ieee754_atan2':
> prog.c:171: Internal compiler error in output_branch, at config/sh/sh.c:1050

It is known that BBRO (basic block reordering optimization) of
GCC does not work well on SH target for unfortunate case. Plain
gcc-3.2/3.2.2 has no workarounds for this issue.
Please give it a try with downgrading the optimization to -O1 or
-O2 -fno-reorder-blocks. If you want to add -fno-reorder-blocks
option only for e_atan2.c, you can add a line like

CFLAGS-e_atan2.os += -fno-reorder-blocks

(for PIC case) to your configparms file in your glibc build directory
to do so.

BTW, my current configparms is:

CC := sh4-unknown-linux-gnu-gcc -B/usr/local/lib/gcc-lib/sh4-unknown-linux-gnu/3.4/
CFLAGS-s_tan.os += -O2
CFLAGS-ns_name.os += -O2
CFLAGS-rtld.os := -finline-limit=4800 --param max-inline-insns-single=4800
no-z-defs=yes

and I'm using make CFLAGS=-O usually.

Regards,
	kaz

[linuxsh-dev] compiler problem gcc 3.2

[peter g. <pga...@li...>]

The trailing program, derived from the glibc -2.3.1 file

sysdeps/ieee754/dbl-64/e_atan2.c

when compiled with gcc 3.2 and also gcc 3.2.2,
generates this error (gcc 3.2.2).
gcc is set up as a cross compiler, host linux pc, target sh4.



prog.c: In function `__ieee754_atan2':
prog.c:171: Internal compiler error in output_branch, at config/sh/sh.c:1050
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.


prog.c
--------------------------------------------------------------------------------


typedef union { int i[2]; double d; } number;
  static const number

     d3 = {{0x55555555, 0xbfd55555} },
     d5 = {{0x999997fd, 0x3fc99999} },
     d7 = {{0x923f7603, 0xbfc24924} },
     d9 = {{0xe5129a3b, 0x3fbc71c6} },
     d11 = {{0x22b13c25, 0xbfb74580} },
     d13 = {{0x8b31cbce, 0x3fb375f0} },

     f3 = {{0x55555555, 0xbfd55555} },
     ff3 = {{0x55555555, 0xbc755555} },
     f5 = {{0x9999999a, 0x3fc99999} },
     ff5 = {{0x9999999a, 0xbc699999} },
     f7 = {{0x92492492, 0xbfc24924} },
     ff7 = {{0x92492492, 0xbc624924} },
     f9 = {{0x1c71c71c, 0x3fbc71c7} },
     ff9 = {{0x1c71c71c, 0x3c5c71c7} },
     f11 = {{0x745d1746, 0xbfb745d1} },
     f13 = {{0x13b13b14, 0x3fb3b13b} },
     f15 = {{0x11111111, 0xbfb11111} },
     f17 = {{0x1e1e1e1e, 0x3fae1e1e} },
     f19 = {{0xbca1af28, 0xbfaaf286} },

     zero = {{0x00000000, 0x00000000} },
     mzero = {{0x00000000, 0x80000000} },
     one = {{0x00000000, 0x3ff00000} },
     inv16 = {{0x00000000, 0x3fb00000} },
     opi = {{0x54442d18, 0x400921fb} },
     opi1 = {{0x33145c07, 0x3ca1a626} },
     mopi = {{0x54442d18, 0xc00921fb} },
     hpi = {{0x54442d18, 0x3ff921fb} },
     hpi1 = {{0x33145c07, 0x3c91a626} },
     mhpi = {{0x54442d18, 0xbff921fb} },
     qpi = {{0x54442d18, 0x3fe921fb} },
     qpi1 = {{0x33145c07, 0x3c81a626} },
     mqpi = {{0x54442d18, 0xbfe921fb} },
     tqpi = {{0x7f3321d2, 0x4002d97c} },
     tqpi1 = {{0x4c9e8a0a, 0x3c9a7939} },
     mtqpi = {{0x7f3321d2, 0xc002d97c} },
     u1 = {{0x00000000, 0x3c314c2a} },
     u2 = {{0x00000000, 0x3bf955e4} },
     u3 = {{0x00000000, 0x3bf955e4} },
     u4 = {{0x00000000, 0x3bf955e4} },
     u5 = {{0x00000000, 0x3aaef2d1} },
     u6 = {{0x00000000, 0x3a6eeb36} },
     u7 = {{0x00000000, 0x3a6eeb36} },
     u8 = {{0x00000000, 0x3a6eeb36} },
     u91 = {{0x00000000, 0x3c6dffc0} },
     u92 = {{0x00000000, 0x3c527bd0} },
     u93 = {{0x00000000, 0x3c3cd057} },
     u94 = {{0x00000000, 0x3c329cdf} },
     ua1 = {{0x00000000, 0x3c3a1edf} },
     ua2 = {{0x00000000, 0x3c33f0e1} },
     ub = {{0x00000000, 0x3a98c56d} },
     uc = {{0x00000000, 0x3a9375de} },
     ud[5] ={{{0x00000000, 0x38c6eddf} },
                      {{0x00000000, 0x35c6ef60} },
                      {{0x00000000, 0x32c6ed2f} },
                      {{0x00000000, 0x23c6eee8} },
                      {{0x00000000, 0x11c6ed16} }},
     ue = {{0x00000000, 0x38900e9d} },
     two8 = {{0x00000000, 0x40700000} },
     two52 = {{0x00000000, 0x43300000} },
     two500 = {{0x00000000, 0x5f300000} },
     twom500 = {{0x00000000, 0x20b00000} },
     twom1022 = {{0x00000000, 0x00100000} };
double __ieee754_atan2(double y,double x) {

  int i,de,ux,dx,uy,dy;
  static const int pr[5]={6,8,10,20,32};
  double ax,ay,u,du,u9,ua,v,vv,dv,t1,t2,t3,t4,t5,t6,t7,t8,
         z,zz,cor,s1,ss1,s2,ss2;
  number num;

  static const int ep= 59768832,
                   em=-59768832;


  num.d = x; ux = num.i[1]; dx = num.i[0];
  if ((ux&0x7ff00000) ==0x7ff00000) {
    if (((ux&0x000fffff)|dx)!=0x00000000) return x+x; }
  num.d = y; uy = num.i[1]; dy = num.i[0];
  if ((uy&0x7ff00000) ==0x7ff00000) {
    if (((uy&0x000fffff)|dy)!=0x00000000) return y+y; }



  if (uy==0x00000000) {
    if (dy==0x00000000) {
      if ((ux&0x80000000)==0x00000000) return zero.d;
      else return opi.d; } }
  else if (uy==0x80000000) {
    if (dy==0x00000000) {
      if ((ux&0x80000000)==0x00000000) return mzero.d;
      else return mopi.d;} }


  if (x==zero.d) {
    if ((uy&0x80000000)==0x00000000) return hpi.d;
    else return mhpi.d; }


  if (ux==0x7ff00000) {
    if (dx==0x00000000) {
      if (uy==0x7ff00000) {
        if (dy==0x00000000) return qpi.d; }
      else if (uy==0xfff00000) {
        if (dy==0x00000000) return mqpi.d; }
      else {
        if ((uy&0x80000000)==0x00000000) return zero.d;
        else return mzero.d; }
    }
  }
  else if (ux==0xfff00000) {
    if (dx==0x00000000) {
      if (uy==0x7ff00000) {
        if (dy==0x00000000) return tqpi.d; }
      else if (uy==0xfff00000) {
        if (dy==0x00000000) return mtqpi.d; }
      else {
        if ((uy&0x80000000)==0x00000000) return opi.d;
        else return mopi.d; }
    }
  }



  ax = x; ay = y;
  de = (uy & 0x7ff00000) - (ux & 0x7ff00000);

  if (de>=ep)
  {
        return ((y>zero.d) ? hpi.d : mhpi.d);
  }
  else if (de<=em)
  {
    if (x>zero.d)
        {
      if ((z=ay/ax)<twom1022.d) return normalized(ax,ay,y,z);
      else return signArctan2(y,z);
        }
    else
        {
                return ((y>zero.d) ? opi.d : mopi.d);
        }
  }

    u=ay/ax;
    t1=134217729.0*(ax); t2=((ax)-t1)+t1; t3=(ax)-t2; t1=134217729.0*(u); t4=((u)-t1)+t1; t5=(u)-t4; v=(ax)*(u); vv=(((t2*t4-v)+t2*t5)+t3*t4)+t3*t5;
    du=((ay-v)-vv)/ax;

        v=u*u; zz=du+u*v*(d3.d+v*(d5.d+v*(d7.d+v*(d9.d+v*(d11.d+v*d13.d)))));
        if ((z=u+(zz-u1.d*u)) == u+(zz+u1.d*u)) return signArctan2(y,z);

        t1=134217729.0*(u); t2=((u)-t1)+t1; t3=(u)-t2; t1=134217729.0*(u); t4=((u)-t1)+t1; t5=(u)-t4; t1=t2*t4; t6=t2*t5+t3*t4; t7=t1+t6; t8=((t1-t7)+t6)+t3*t5; t8=((u)*(du)+(du)*(u))+t8; v=t7+t8; vv=(t7-v)+t8;
        s1=v*(f11.d+v*(f13.d+v*(f15.d+v*(f17.d+v*f19.d))));
        t1=(f9.d)+(s1); t2=(((f9.d) < 0 ? -(f9.d) : (f9.d))>((s1) < 0 ? -(s1) : (s1))) ? (((((f9.d)-t1)+(s1))+(zero.d))+(ff9.d)) : (((((s1)-t1)+(f9.d))+(ff9.d))+(zero.d)); s2=t1+t2; ss2=(t1-s2)+t2;
        t1=134217729.0*(v); t2=((v)-t1)+t1; t3=(v)-t2; t1=134217729.0*(s2); t4=((s2)-t1)+t1; t5=(s2)-t4; t1=t2*t4; t6=t2*t5+t3*t4; t7=t1+t6; t8=((t1-t7)+t6)+t3*t5; t8=((v)*(ss2)+(vv)*(s2))+t8; s1=t7+t8; ss1=(t7-s1)+t8;
        t1=(f7.d)+(s1); t2=(((f7.d) < 0 ? -(f7.d) : (f7.d))>((s1) < 0 ? -(s1) : (s1))) ? (((((f7.d)-t1)+(s1))+(ss1))+(ff7.d)) : (((((s1)-t1)+(f7.d))+(ff7.d))+(ss1)); s2=t1+t2; ss2=(t1-s2)+t2;
        t1=134217729.0*(v); t2=((v)-t1)+t1; t3=(v)-t2; t1=134217729.0*(s2); t4=((s2)-t1)+t1; t5=(s2)-t4; t1=t2*t4; t6=t2*t5+t3*t4; t7=t1+t6; t8=((t1-t7)+t6)+t3*t5; t8=((v)*(ss2)+(vv)*(s2))+t8; s1=t7+t8; ss1=(t7-s1)+t8;
        t1=(f5.d)+(s1); t2=(((f5.d) < 0 ? -(f5.d) : (f5.d))>((s1) < 0 ? -(s1) : (s1))) ? (((((f5.d)-t1)+(s1))+(ss1))+(ff5.d)) : (((((s1)-t1)+(f5.d))+(ff5.d))+(ss1)); s2=t1+t2; ss2=(t1-s2)+t2;
        t1=134217729.0*(v); t2=((v)-t1)+t1; t3=(v)-t2; t1=134217729.0*(s2); t4=((s2)-t1)+t1; t5=(s2)-t4; t1=t2*t4; t6=t2*t5+t3*t4; t7=t1+t6; t8=((t1-t7)+t6)+t3*t5; t8=((v)*(ss2)+(vv)*(s2))+t8; s1=t7+t8; ss1=(t7-s1)+t8;
        t1=(f3.d)+(s1); t2=(((f3.d) < 0 ? -(f3.d) : (f3.d))>((s1) < 0 ? -(s1) : (s1))) ? (((((f3.d)-t1)+(s1))+(ss1))+(ff3.d)) : (((((s1)-t1)+(f3.d))+(ff3.d))+(ss1)); s2=t1+t2; ss2=(t1-s2)+t2;
    t1=134217729.0*(v); t2=((v)-t1)+t1; t3=(v)-t2; t1=134217729.0*(s2); t4=((s2)-t1)+t1; t5=(s2)-t4; t1=t2*t4; t6=t2*t5+t3*t4; t7=t1+t6; t8=((t1-t7)+t6)+t3*t5; t8=((v)*(ss2)+(vv)*(s2))+t8; s1=t7+t8; ss1=(t7-s1)+t8;
    t1=134217729.0*(u); t2=((u)-t1)+t1; t3=(u)-t2; t1=134217729.0*(s1); t4=((s1)-t1)+t1; t5=(s1)-t4; t1=t2*t4; t6=t2*t5+t3*t4; t7=t1+t6; t8=((t1-t7)+t6)+t3*t5; t8=((u)*(ss1)+(du)*(s1))+t8; s2=t7+t8; ss2=(t7-s2)+t8;
    t1=(u)+(s2); t2=(((u) < 0 ? -(u) : (u))>((s2) < 0 ? -(s2) : (s2))) ? (((((u)-t1)+(s2))+(ss2))+(du)) : (((((s2)-t1)+(u))+(du))+(ss2)); s1=t1+t2; ss1=(t1-s1)+t2;
    if ((z=s1+(ss1-u5.d*s1)) == s1+(ss1+u5.d*s1)) return signArctan2(y,z);
    return atan2Mp(x,y,pr);
}
--------------------------------------------------------------------------------

-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

Re: [linuxsh-dev] Cache bug on SH-3/4

[Paul M. <pau...@ti...>]

On Fri, 2003-02-14 at 10:17, David McCullough wrote:
> I wouldn't say the 7751/7750 and the 7751R are that different code wise
> to manage it,  just the extra ways to deal with.  Of course underneath
> they may be plenty different ;-)
>=20
Extra ways makes a considerable difference in and of itself. Naturally
there's also OC RAM differences, which is a bit more annoying.

I've been playing with getting most of that dealt with relatively
transparently in the restructure branch, but haven't finished off the
way bit selection in the flush yet (also no 7751R/7750R to test on).=20

Good thing probing works so we don't have to hardcode anything..

> The cache-sh4.c I used in the test is a mega hack version I used to get
> multiple ways going (with experimentation code still in there).  I can
> send you a copy if you want.  It currently has the 7751R support
> hardcoded on,  but the current version has it disabled,  not that it
> seems to matter in practice if you use the 7751R code on the 7751.
>=20
Sure, pass it along, could be interesting.

--=20
Paul Mundt <pau...@ti...>
TimeSys Corporation

Re: [linuxsh-dev] Cache bug on SH-3/4

[David M. <da...@sn...>]

Jivin Paul Mundt lays it down ...
> David,
> 
> Interesting. I've been testing on my Solution Engines .. 7709A and 7750.
> The 7751R has a vastly different cache configuration. Does your

I wouldn't say the 7751/7750 and the 7751R are that different code wise
to manage it,  just the extra ways to deal with.  Of course underneath
they may be plenty different ;-)

> arch/sh/mm/cache-sh4.c properly deal with the multiple ways?

Yes.  I would have tried it on a 7751 but it's net chip has gone west
and I am working from home (friday night),  so I won't be able to try it
till monday.

> I've also only tested this using write-back. I suppose I should give
> write-through a try as well, but since it's mostly a reading issue, I
> doubt that'll have much of an effect.

I am using copyback/write back. 

> Also, are you running stock LinuxSH CVS? or are you on a proprietary
> vendor tree that might have some other flushing happening somewhere?

I am running a mostly stock Linus kernel with patches for our targets.

Actually,  I just tried it again in compatibility mode (ie., stock 7751),
also worked fine.

The cache-sh4.c I used in the test is a mega hack version I used to get
multiple ways going (with experimentation code still in there).  I can
send you a copy if you want.  It currently has the 7751R support
hardcoded on,  but the current version has it disabled,  not that it
seems to matter in practice if you use the 7751R code on the 7751.

Cheers,
Davidm

> On Fri, 2003-02-14 at 09:36, David McCullough wrote:
> > I just tried this on my 2.4.17 kernel on the 7751R/SH4 with no crash
> > and it output 0 as I suspect it is supposed to.  I can try some more
> > platforms/combos monday when I am back in the office if you like.
> > 
> > Not sure that it worked for me means much though,  could be just be the
> > cache state/entries are quite different between our platforms.
> > 
> 
> Regards,
> 
> -- 
> Paul Mundt <pau...@ti...>
> TimeSys Corporation



-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [linuxsh-dev] Cache bug on SH-3/4

[David M. <da...@sn...>]

Hi Paul,

I just tried this on my 2.4.17 kernel on the 7751R/SH4 with no crash
and it output 0 as I suspect it is supposed to.  I can try some more
platforms/combos monday when I am back in the office if you like.

Not sure that it worked for me means much though,  could be just be the
cache state/entries are quite different between our platforms.

Cheers,
Davidm

Jivin Paul Mundt lays it down ...
> I've hit what looks to be another cache bug (looks like its an alias
> issue), and so far it seems to hit both SH-3 and 4. (I haven't tested
> SH-2 or 5 yet).
> 
> The problem pops up when doing an mmap() of /dev/zero and then reading
> from it, the read is sometimes 0, but most of the time ends up getting
> back garbage and promptly segfaulting.
> 
> I've attached my testcode for this as well. The fault happens right on
> the read.
> 
> I've managed to fix this on SH-4 (patch attached) by doing an all out
> flush_cache_all() after the activate_context() in switch_mm() .. not a
> very optimal solution, but seems to do the right thing for now.
> 
> Unfortunately this same fix doesn't help SH-3 any (after implicitly
> wrapping flush_cache_all() to cache_wback_all()).
> 
> Anyone seen this before?
> 
> Regards,
> 
> -- 
> Paul Mundt <pau...@ti...>
> TimeSys Corporation






-- 
David McCullough:    Ph: +61 7 3435 2815  http://www.SnapGear.com
da...@sn...  Fx: +61 7 3891 3630  Custom Embedded Solutions + Security

Re: [linuxsh-dev] Cache bug on SH-3/4

[Stuart M. <stu...@st...>]

Hi Paul

This looks like a problem I hit a short while ago when using ssh. Turns
out to be a problem in the generic kernel code, which is using a
clear_highpage() to zero the page, which doesn't have the necessary extra
cache alias prevention code. Ideally it should be replaced by
clear_user_page(), but the virtual address where the page is going to be
mapped isn't available at that point in the code.

At this point I had a look in Marcello's tree in BK, and it turns out
somebody else has already fixed this problem by simply adding a call to
flush_dcache_page(). IIRC this is a post 2.4.20 change.

I'm running with the attached patch to a 2.4.18 tree, and your test
code appears to work for me on an SH4, I've not tried anything else.

Hope this helps

Stuart

On Fri, 14 Feb 2003 08:47:07 -0500 pau...@ti... wrote:

> I've hit what looks to be another cache bug (looks like its an alias
> issue), and so far it seems to hit both SH-3 and 4. (I haven't tested
> SH-2 or 5 yet).
> 
> The problem pops up when doing an mmap() of /dev/zero and then reading
> from it, the read is sometimes 0, but most of the time ends up getting
> back garbage and promptly segfaulting.
> 
> I've attached my testcode for this as well. The fault happens right on
> the read.
> 
> I've managed to fix this on SH-4 (patch attached) by doing an all out
> flush_cache_all() after the activate_context() in switch_mm() .. not a
> very optimal solution, but seems to do the right thing for now.
> 
> Unfortunately this same fix doesn't help SH-3 any (after implicitly
> wrapping flush_cache_all() to cache_wback_all()).
> 
> Anyone seen this before?
> 
> Regards,
> 
> -- 
> Paul Mundt <pau...@ti...>
> TimeSys Corporation
> 

[linuxsh-dev] Cache bug on SH-3/4

[Paul M. <pau...@ti...>]

I've hit what looks to be another cache bug (looks like its an alias
issue), and so far it seems to hit both SH-3 and 4. (I haven't tested
SH-2 or 5 yet).

The problem pops up when doing an mmap() of /dev/zero and then reading
from it, the read is sometimes 0, but most of the time ends up getting
back garbage and promptly segfaulting.

I've attached my testcode for this as well. The fault happens right on
the read.

I've managed to fix this on SH-4 (patch attached) by doing an all out
flush_cache_all() after the activate_context() in switch_mm() .. not a
very optimal solution, but seems to do the right thing for now.

Unfortunately this same fix doesn't help SH-3 any (after implicitly
wrapping flush_cache_all() to cache_wback_all()).

Anyone seen this before?

Regards,

-- 
Paul Mundt <pau...@ti...>
TimeSys Corporation

[linuxsh-dev] mmzone.h

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

Upon request of Yoshii-san, I've found my mmzone.h (as of Aug. 2001).
It was the time when I've joined Linux-10 event at Sunnyvale.

It's only for HP690, but people can use it for another purpose.

--------------------------
/*
 *  linux/include/asm-sh/mmzone.h
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
#ifndef __ASM_SH_MMZONE_H
#define __ASM_SH_MMZONE_H

#include <linux/config.h>

/* Currently, just for HP690 */
#define PHYSADDR_TO_NID(phys)	((((phys) - __MEMORY_START) >= 0x01000000)?1:0)
#define NR_NODES 2

extern pg_data_t discontig_page_data[NR_NODES];
extern bootmem_data_t discontig_node_bdata[NR_NODES];

#ifdef CONFIG_DISCONTIGMEM
/*
 * Following are macros that each numa implmentation must define.
 */

/*
 * Given a kernel address, find the home node of the underlying memory.
 */
#define KVADDR_TO_NID(kaddr)	PHYSADDR_TO_NID(__pa(kaddr))

/*
 * Return a pointer to the node data for node n.
 */
#define NODE_DATA(nid)		(&discontig_page_data[nid])

/*
 * NODE_MEM_MAP gives the kaddr for the mem_map of the node.
 */
#define NODE_MEM_MAP(nid)	(NODE_DATA(nid)->node_mem_map)

#define phys_to_page(phys)						\
({ unsigned int node = PHYSADDR_TO_NID(phys); 		      		\
   NODE_MEM_MAP(node)				 		 	\
     + (((phys) - NODE_DATA(node)->node_start_paddr) >> PAGE_SHIFT); })

static inline int is_valid_page(struct page *page)

#define VALID_PAGE(page)						\
({									\
	unsigned int i;							\
									\
	for (i = 0; i < NR_NODES; i++) {				\
		if (page >= NODE_MEM_MAP(i) &&				\
		    page < NODE_MEM_MAP(i) + NODE_DATA(i)->node_size)	\
			break;						\
	}								\
	i < NR_NODES ? 1 : 0;						\
})

#define page_to_phys(page)	PHYSADDR(page_address(page))

#endif /* CONFIG_DISCONTIGMEM */
#endif

Re: [linuxsh-dev] the watchdog overflow too fast.

[Jeremy S. <jas...@pa...>]

Spark.Kuo(*=A2=95=DA*a) wrote:

> Dear all:
>         I have ported the linux kernel 2.4.19 on my board using sh4=
 7751R.When i enable the watchdog,the board reboot immediately,someti=
mes the sh_wdt_ping() has entered several times, but sometimes not.
>         It seem to be that the watchdog overflow before the sh_wdt_=
ping() function.
>         i think that the sh_wdt_ping() function would set WTCNT to =
0x0 periodly,before the WDIOF_SETTIMEOUT settting.
>         but my watchdog reboot before the sh_wdt_ping() periodly re=
setting.
>         Has anyone some comments?

/* Yes, sh_wdt_ping() should clear WTCNT, but as a timer function it =
only does so when the timer pops, which I believe is dependent on the=
 kernel tick... and the longest setting for the watchdog is still
too fast for the normal 10ms tick.  Since you can't add bits to the c=
ounter, I'd guess all you can do is either slow down the base board c=
lock so the watchdog timeout is slow enough, or modify the kernel to
use a faster tick. */

--Jeremy Siegel

[linuxsh-dev] the watchdog overflow too fast.

[<Spa...@gi...>]

Dear all:
	I have ported the linux kernel 2.4.19 on my board using sh4 7751R.When =
i enable the watchdog,the board reboot immediately,sometimes the =
sh_wdt_ping() has entered several times, but sometimes not.=20
	It seem to be that the watchdog overflow before the sh_wdt_ping() =
function.
	i think that the sh_wdt_ping() function would set WTCNT to 0x0 =
periodly,before the WDIOF_SETTIMEOUT settting.
	but my watchdog reboot before the sh_wdt_ping() periodly resetting.
	Has anyone some comments?
	Thanks

=09

[linuxsh-dev] Rebuilding by linux-sh tools

[Adrian M. <Ad...@mc...>]

I want to do this (previous installation gone to the dogs). Which set of
tools and patches are recommended?

Adrian

[linuxsh-dev] Re: memcpy/TLBMiss patch assembled for 2.4.18cvs

[Masahiro A. <m-...@aa...>]

I still haven't being able to make TLB-Miss handling speed-up part work on
my SolutionEngine.
I must do something else right now so my investigation pends now. I
really appreciate if anyone can help on this. If anyone can give more
info/suggestion/patch, I'll try that.

In the mean time, I've put "memcpy speed-up" part only patch on the
server, for anyone interested.
<ftp://ftp.aandd.co.jp/pub/linuxsh/work/20030129/>

On Mon, 27 Jan 2003 14:10:42 +0900
Masahiro Abe <m-...@aa...> wrote:

> I'm sorry but my test had a mistake...
> 
> Announced patch doesn't work on my SolutionEngine 7750S.
> "Unable to handle kernel paging request" occurs inside remap_area_pte.
> It's called as
> start_kernel
>   |-->mem_init
>         |-->p3_cache_init
>               |-->remap_area_pages
>                     |-->remap_area_pmd
>                           |-->remap_area_pte
> Will do some more investigation...
> 
> On Sun, 26 Jan 2003 19:06:18 +0900
> Masahiro Abe <m-...@aa...> wrote:
> 
> > I'm trying Mr. Stuart Menefy's "memcpy speed-up" and "TLB Miss Handling
> > optimization" patch with 2.4.18cvs source, on SolutionEngine 7750S, in
> > the hope that they may improve the behavior of RTLinux-patched kernel.
> > 
> > Now it's build and seems to work without problems. I don't have
> > performance figure yet, but thought some of you might try his work with
> > relatively easier way, I've put simple patch files on our server.
> > 
> > <ftp://ftp.aandd.co.jp/pub/linuxsh/work/20030126/>
> > 
> > There are three patches there.
> > -diff-2.4.18-cvs.diff.bz2 is to apply changes to stock 2.4.18 kernel,
> > and make it same as the "linux-2_4_18" tagged cvs source.
> > -diff-2.4.18cvs-se.diff.bz2 is to apply to the "linux-2_4_18" tagged cvs
> > source, and make it boot from CompactFlash on SolutionEngine 7750S. This
> > is not needed for other platforms.
> > -diff-2.4.18se-su-20030126-1.diff.bz2 is the main patch file of today.
> > This is to apply to the "linux-2_4_18" tagged cvs source. Includes "memcpy
> > speed-up" and "TLB Miss Handling optimization" patch.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

Re[2]: [linuxsh-dev] Improved TLB miss handler (second attempt)

[Masahiro A. <m-...@aa...>]

On Mon, 27 Jan 2003 20:24:28 +0900
Masahiro Abe <m-...@aa...> wrote:

> Thank you for reading till this point.
> I suspect that some changes are missing from the patch, or the patch
> works only for 2.4.20-pre10.

I tried with patch with 2.4.20-pre11 and got the same result.

---
LILO boot: first-image
Loading linux............done.
Uncompressing Linux... Ok, booting the kernel.
Linux version 2.4.20-pre11-sh (ro...@ad...) (gcc version 3.0.3) #2 Mon Jan 27 21:20:31 JST 2003
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: ro root=301 BOOT_FILE=/boot/zImage mem=64M sh_mv=SolutionEngine ide1=noprobe console=ttySC1,115200
ide_setup: ide1=noprobe
Setting GDB trap vector to 0x80000100
SH RTC: invalid value, resetting to 1 Jan 2000
CPU clock: 200.01MHz
Bus clock: 66.67MHz
Module clock: 33.33MHz
Interval = 83340
Calibrating delay loop... 199.47 BogoMIPS
Memory: 63516k/65536k available (1069k kernel code, 2020k reserved, 33k data, 40k init)
Unable to handle kernel paging request at virtual address 0c146000
pc = 8c00fd98
*pde = 8c001000
Oops: 0000

PC  : 8c00fd98 SP  : 8c117f9c SR  : 40008100 TEA : 0c146000    Not tainted
R0  : 0c146000 R1  : 00400000 R2  : 003fffff R3  : 00001000
R4  : 8c146000 R5  : 8c146000 R6  : ba2e8ba3 R7  : 8c013be0
R8  : 00000000 R9  : 00000000 R10 : 00004000 R11 : 00000000
R12 : 0c146000 R13 : 00004000 R14 : c0000000
MACH: 0004deb8 MACL: 00000146 GBR : ffffffff PR  : 8c00fd5a
Kernel panic: Attempted to kill the idle task!
In idle task - not syncing
---

TEA is a little different from 2.4.18 (was 0c13f000).

=================================
Masahiro ABE, A&D Co., Ltd. Japan

Re: [linuxsh-dev] Improved TLB miss handler (second attempt)

[Masahiro A. <m-...@aa...>]

Menefy-san and all, sorry for relatively long post,

On Mon, 18 Nov 2002 11:51:32 +0000
Stuart Menefy <stu...@st...> wrote:

> Folks
> 
> Attached is my second attempt at an improved TLB miss handler.
> 
> Unfortuntaly the previous patch was corrupted, so I've double checked this
> one, and it applies cleanly to 2.4 brach HEAD (2.4.20-pre10) and almost
> cleanly to 2.4.18.
> 
> This should build for both SH3 and SH4, although it has only been tested
> on SH4.
> 
> As always, all comments welcome
> 
> Stuart

I've tried your patch on "linux-2_4_18" tagged CVS source, and ran on
SolutionEngine 7750S, but kernel oops at startup.

I really want to see the speed-up of TLB-Miss handling, due to the
likelihood of fact that it may be the source of large latency of RTLinux
patch.

I would be more than happy if you can spend a little time to read my
report below, and give me some thought you might have. Only if you have
such time, of course.

1. I've taken stock 2.4.18 kernel and dropped "linux-2_4_18" tagged CVS
source in it. Then I've simply applied "2.4.20-tlb" file as patch. As
Mundt-san pointed out, it #error in entry.S. I've simply put "!" before
#error.

2. I've done make xconfig dep zImage, and put zImage onto CompactFlash.
Kernel starts booting, but "Oops" in mem_init. I've put some debug
printk and see some values. The output is like this:

---
Memory: 63288k/65536k available (1044k kernel code, 2248k reserved, 32k data, 40k init)
remap_area_pages begin
-->remap_area_pages(address = 0xc0000000,
                    phys_addr = 0x00000000,
                    size = 0x00004000,
                    flags = 0x00000008)
-->remap_area_pmd(pmd = 0x8c11dc28,
                  address = 0xc0000000,
                  size = 0x00004000,
                  phys_addr = 0x00000000,
                  flags = 0x00000008)
   in pte_alloc()
   pmd_none(*pmd) is true
   new = 0x8c13f000
   pmd_val(*pmd) = 0x8c13f000
   pmd_page(*(pmd)) = 0x0c13f000
   __pte_offset(address) = 0x00000000
-->remap_area_pte(pte = 0x0c13f000,
                  address = 0x00000000,
                  size = 0x00004000,
                  phys_addr = 0x00000000,
                  flags = 0x00000008)
Unable to handle kernel paging request at virtual address 0c13f000
pc = 8c00ddde
*pde = 8c001000
Oops: 0000

PC  : 8c00ddde SP  : 8c111f94 SR  : 40008100 TEA : 0c13f000    Not tainted
R0  : 00000026 R1  : 00000000 R2  : 40008100 R3  : 00400000
R4  : 8c1076c4 R5  : 00000001 R6  : 00000001 R7  : 8c011920
R8  : 00001000 R9  : 00004000 R10 : 00000000 R11 : 8c011b40
R12 : 00000000 R13 : 0c13f000 R14 : 00000000
MACH: 0004deb8 MACL: 00000000 GBR : b7e3fb6c PR  : 8c00ddbe
Kernel panic: Attempted to kill the idle task!
In idle task - not syncing
---

"pte" to remap_area_pte seems wrong.

3.I've put same printk to the flesh 2.4.18cvs source and the output was:
---
   in pte_alloc()
   pmd_none(*pmd) is true
   new = 0x8c13f000
   pmd_val(*pmd) = 0x0c13f564
   pmd_page(*(pmd)) = 0x8c13f000
   __pte_offset(address) = 0x00000000
-->remap_area_pte(pte = 0x8c13f000,
---

"pte" looks fine here.

4.I thought "pmd_populate" is generating invalid value, so changed it
from:
extern inline void pmd_populate(struct mm_struct *mm, pmd_t *pmd, pte_t *pte)
{
	set_pmd(pmd, __pmd((unsigned long)pte));
}
to:
#define pmd_populate(mm, pmd, pte) \
		set_pmd(pmd, __pmd(__pa(pte)))
Then, 
---
   in pte_alloc()
   pmd_none(*pmd) is true
   new = 0x8c13f000
   pmd_val(pmd) = 0x0c13f000
   pmd_page(*(pmd)) = 0x8c13f000
   __pte_offset(address) = 0x00000000
-->remap_area_pte(pte = 0x8c13f000,
---
kernel passes mem_init, but just around when init starts, system resets.

5.I reversed my thinking. Maybe pmd_populate is fine, but pmd_page is to
blame. So I changed it from:
#define pmd_page(pmd) ((unsigned long) __va(pmd_val(pmd)))
to:
#define pmd_page(pmd) ((unsigned long) pmd_val(pmd))

kernel passes mem_init again, but just around when init starts, system
freezes.

Thank you for reading till this point.
I suspect that some changes are missing from the patch, or the patch
works only for 2.4.20-pre10.

I appreciate any input on this matter.

=================================
Masahiro ABE, A&D Co., Ltd. Japan

[linuxsh-dev] Re: memcpy/TLBMiss patch assembled for 2.4.18cvs

[Masahiro A. <m-...@aa...>]

I'm sorry but my test had a mistake...

Announced patch doesn't work on my SolutionEngine 7750S.
"Unable to handle kernel paging request" occurs inside remap_area_pte.
It's called as
start_kernel
  |-->mem_init
        |-->p3_cache_init
              |-->remap_area_pages
                    |-->remap_area_pmd
                          |-->remap_area_pte
Will do some more investigation...

On Sun, 26 Jan 2003 19:06:18 +0900
Masahiro Abe <m-...@aa...> wrote:

> I'm trying Mr. Stuart Menefy's "memcpy speed-up" and "TLB Miss Handling
> optimization" patch with 2.4.18cvs source, on SolutionEngine 7750S, in
> the hope that they may improve the behavior of RTLinux-patched kernel.
> 
> Now it's build and seems to work without problems. I don't have
> performance figure yet, but thought some of you might try his work with
> relatively easier way, I've put simple patch files on our server.
> 
> <ftp://ftp.aandd.co.jp/pub/linuxsh/work/20030126/>
> 
> There are three patches there.
> -diff-2.4.18-cvs.diff.bz2 is to apply changes to stock 2.4.18 kernel,
> and make it same as the "linux-2_4_18" tagged cvs source.
> -diff-2.4.18cvs-se.diff.bz2 is to apply to the "linux-2_4_18" tagged cvs
> source, and make it boot from CompactFlash on SolutionEngine 7750S. This
> is not needed for other platforms.
> -diff-2.4.18se-su-20030126-1.diff.bz2 is the main patch file of today.
> This is to apply to the "linux-2_4_18" tagged cvs source. Includes "memcpy
> speed-up" and "TLB Miss Handling optimization" patch.
> 
> I've read Mr. Stuart Menefy's original posts carefully and tried to
> apply his changes as intended, but there may be some error due to my
> lack of understanding. If such is found, please let everybody know.
> 
> to Mr. Stuart Menefy:
> Regarding TLBMiss patch, I've moved "PCC_MASK" to asm-sh/mmu_context.h
> and use in kernel/entry.S and mm/fault.c, since I thought the change in
> update_mmu_cache is related to this flag. Please let me know if this
> assumption is correct. Thanks.
> 
> =================================
> Masahiro ABE, A&D Co., Ltd. Japan
> 

=================================
Masahiro ABE, A&D Co., Ltd. Japan