linuxsh-dev

Re: [linuxsh-dev] newlib

[<su...@it...>]

I uploaded rpms for RedHat 6.2 at http://www.sh-linux.org/tools
which contains binutils(for newlib-sh), gcc(for newlib-sh) and newlib-sh.
I will upload srpms soon.

newlib and glibc are compiled for kernel version 2.2.x, but they would run 
on kernel 2.4

these are not yet tested well sorry.

Re: [linuxsh-dev] newlib

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

I don't have any experience with newlib, but most important thing
which you need to change is system call interface, I think.

Besides, I think that Sugioka-san used newlib in his SuperH product.
You'd be better visiting his site: www.sh-linux.org

If the entire system is small enough, newlib would be good, if not,
GNU C library is better since it works as shared library.
-- 

Re: [linuxsh-dev] newlib

[<gn...@ya...>]

--- Bryan Rittmeyer <br...@ix...> wrote: > Greg
Banks wrote:
> 
> >   Back in March, Mitch & I got newlib
> almost-working (i.e. to the
> > point where a newlib program linked) but we
> haven't done any work
> > on it since.
> 
> What specifically did you have to do to get it to
> build?

  Firstly, some small tweaks to get newlib to compile,
mostly to do with ELF symbol underscore prefixing
IIRC.  Secondly, a tweak to gcc's specs file to get
gcc to tell the linker the right crt files.

  The actual changes were not large, the effort
went into figuring out exactly how to make them.

> [right now i'm just trying to get a kernel up, but
> I'd like to be able
> to run user code eventually]

  Yep.

Greg.

=====
This address is temporary.

_____________________________________________________________________________
http://geocities.yahoo.com.au - Yahoo! Australia & NZ GeoCities
- Build your own Web Site - for free!

Re: [linuxsh-dev] newlib

[Bryan R. <br...@ix...>]

Greg Banks wrote:

>   Back in March, Mitch & I got newlib almost-working (i.e. to the
> point where a newlib program linked) but we haven't done any work
> on it since.

What specifically did you have to do to get it to build?

[right now i'm just trying to get a kernel up, but I'd like to be able
to run user code eventually]

Cheers,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] newlib

[Greg B. <gn...@al...>]

Bryan Rittmeyer wrote:
> 
> Hi,

G'day

> 
> Oh, I forgot to ask as part of my last post... Does anyone have any
> information on using newlib instead of glibc on the SH4? glibc is
> overkill for the embedded system I am working with.

  Back in March, Mitch & I got newlib almost-working (i.e. to the
point where a newlib program linked) but we haven't done any work
on it since.

Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] gcc problems?

[Greg B. <gn...@al...>]

NIIBE Yutaka wrote:
> 
>  > Right now I am building gcc using the
>  > ftp://ftp.m17n.org/pub/super-h/gcc-2.95.2-000228.diff.gz patch, and will
>  > try that. Are there any known bugs in the gcc-core in linuxsh cvs?
> 
> I think we don't have any bugs.

  The gcc-core from linuxsh CVS works fine for me.

Greg.
-- 
Fight spam http://www.caube.org.au/
If it's a choice between being a paranoid, hyper-suspicious global
village
idiot, or a gullible, mega-trusting sheep, I don't look good in mint
sauce. 
 - jd, slashdot, 11Feb2000.

[linuxsh-dev] newlib

[Bryan R. <br...@ix...>]

Hi,

Oh, I forgot to ask as part of my last post... Does anyone have any
information on using newlib instead of glibc on the SH4? glibc is
overkill for the embedded system I am working with.

Thanks again guys,

Bryan Rittmeyer
mailto:br...@ix...

[linuxsh-dev] bootmem.c/newlib

[Bryan R. <br...@ix...>]

Hello again linuxsh-dev,

I am now having some trouble getting the latest CVS kernel to boot. It
gets past the Linux banner and then generates hundreds of lines of
paging errors. Here is the GDB output:

bryan@mtdew:~/cvs/sh/kernel$ sh-linux-gnu-gdb
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=sh-linux-gnu".
0xa00018c6 in ?? ()
Loading section .empty_zero_page, size 0x1c lma 0xa8003000
Loading section .text, size 0x63ac8 lma 0xa8004000
Loading section .rodata, size 0xdd23 lma 0xa8067ac8
Loading section __ex_table, size 0x1208 lma 0xa80757f0
Loading section .data, size 0x6ab8 lma 0xa80769f8
Loading section .exitcall.exit, size 0x14 lma 0xa807d4b0
Loading section .data.init_task, size 0x2000 lma 0xa807e000
Loading section .text.init, size 0x5878 lma 0xa8080000
Loading section .data.init, size 0x2db lma 0xa8085878
Loading section .setup.init, size 0x88 lma 0xa8085b60
Loading section .initcall.init, size 0x34 lma 0xa8085be8
Loading section .machvec.init, size 0x2f8 lma 0xa8085c1c
Loading section .data.cacheline_aligned, size 0xac0 lma 0xa8086000
Start address 0xa8004000 , load size 532130
Transfer rate: 29157 bits/sec.
(gdb) cont
Continuing.
Linux version 2.4.0-test6 (bryan@mtdew) (gcc version 2.95.2 19991024
(release)) #2 Tue Aug 22 16:38:28 PDT 2000
kernel BUG at bootmem.c:83!
hm, page 00f00000 reserved twice.
hm, page 00f01000 reserved twice.
hm, page 00f02000 reserved twice.
hm, page 00f03000 reserved twice.
hm, page 00f04000 reserved twice.
hm, page 00f05000 reserved twice.
.
.
.

And so on indefinitely through every page in the memory space. I get the
same results with Linux-2.4.0-test6 and the CVS kernel. Anyone seen this
before or know what may cause it?

Thanks,

Bryan Rittmeyer
mailto:br...@ix...

[linuxsh-dev] loading kernel with gdb

[Bryan R. <br...@ix...>]

Mitch Davis wrote:

> Give the GDB stub a try as well.  Please note that Greg and I had
> troubles with loading the kernel with the stub that went away
> when we hacked the linker script so the kernel was linked to run
> at 0x80000000 but load at 0xA0000000 (the uncached area).  Please
> tell me if you're interested in our patch.  (Niibe-san didn't
> like it - he thinks we'd be better off finding the cause of this
> problem).

Can you give me more info on this patch and what your problem was? Now
that I have the GDB stub working, I am running into early trouble with
the kernel. Here is the GDB output:

---
bryan@mtdew:~/cvs/sh/kernel$ sh-linux-gnu-gdb
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=sh-linux-gnu".
0x8000402 in ?? ()
Loading section .empty_zero_page, size 0x1c lma 0x88101000
Loading section .text, size 0x63ce8 lma 0x88102000
Loading section .rodata, size 0xdd37 lma 0x88165ce8
Loading section __ex_table, size 0x1208 lma 0x88173a20
Loading section .data, size 0x6ab8 lma 0x88174c28
Loading section .exitcall.exit, size 0x14 lma 0x8817b6e0
Loading section .data.init_task, size 0x2000 lma 0x8817c000
Loading section .text.init, size 0x5878 lma 0x8817e000
Loading section .data.init, size 0x2db lma 0x88183878
Loading section .setup.init, size 0x88 lma 0x88183b60
Loading section .initcall.init, size 0x34 lma 0x88183be8
Loading section .machvec.init, size 0x2f8 lma 0x88183c1c
Loading section .data.cacheline_aligned, size 0xac0 lma 0x88184000
Start address 0x88102000 , load size 532694
Transfer rate: 29188 bits/sec.
(gdb) cont
Continuing.
Can't send signals to this remote system.  SIGBUS not sent.

Program received signal SIGBUS, Bus error.
0x88102000 in _stext ()
(gdb) 
---

What a letdown... I thought it would work the first time. ;-) Any idea
what can cause a SIGBUS before the first line of kernel output even
shows up?

(Same problem with the CVS kernel source and with linux-2.4.0-test6)

Thanks,

Bryan Rittmeyer
mailto:br...@ix...

[linuxsh-dev] sh-ipl working

[Bryan R. <br...@ix...>]

Hello,

I finally got the SH4 gdb stub working properly! (so it would seem
anyway) It turns out there was absolutely nothing wrong with gcc, the
reason I was seeing such odd behavior was due to the way I was linking
the object code output, putting the ROM, RAM, and STACK into the same
64kb SRAM. Apparently the SH4 architecture doesn't like that, so I moved
the RAM segment into the SDRAM as NIIBE suggested and all of the strange
string handling behavior is now gone. So it's just a matter of building
and loading a kernel, and from there a working ramdisk image. Then I'll
have a full linux system running on the embedded SH4...

It took a week and help from about a dozen people, but it's nice to have
everything finally make sense. Thanks to everyone for their help. I'm
going home happy tonight...

Regards,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] gcc problems?

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

Bryan Rittmeyer wrote:
 > I have tried the stub with the exact same BSC init values we use
 > successfully for our non-linux code, and still have the same problem
 > (init-sjb.S has that code)... I am also certain it is not a hardware
 > issue, since very complicated RTOS code runs on the same board with no
 > trouble.

But init-sjb.S is not used for your configuration, according to the
Makefile you provided.  With the configuration, init-bare.S is used.
What's wrong here?  Could you please check it and if possible, 
please tesit it out with RAM of SDRAM.

 > Right now I am building gcc using the
 > ftp://ftp.m17n.org/pub/super-h/gcc-2.95.2-000228.diff.gz patch, and will
 > try that. Are there any known bugs in the gcc-core in linuxsh cvs?

I think we don't have any bugs.
-- 

Re: [linuxsh-dev] gcc problems?

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

NIIBE Yutaka <gn...@ch...> wrote:
>Bryan Rittmeyer wrote:
>> gcc: I am using latest gcc-core cvs, checked out around 12:00 PST today.
>> Built exactly according to instructions above. I have also worked with
>> older cvs versions from last week.
>
>I think you mean CVS of our linuxsh of sourceforge.net.  Please note
>that Kaz' comment is for GNU's development version, which is not
>relevant to sorceforge version, I believe.

Yep, I'm misunderstood.  Sorry Bryan and thank you Niibe-san.

	kaz

Re: [linuxsh-dev] gcc problems?

[Bryan R. <br...@ix...>]

NIIBE Yutaka wrote:

> OK, I see.  Then next thing to check is the setting of BSC.  It seems
> for me that your RAM is not working well (for write).  Please check
> the value of BSC setting.

I have tried the stub with the exact same BSC init values we use
successfully for our non-linux code, and still have the same problem
(init-sjb.S has that code)... I am also certain it is not a hardware
issue, since very complicated RTOS code runs on the same board with no
trouble. Right now I am building gcc using the
ftp://ftp.m17n.org/pub/super-h/gcc-2.95.2-000228.diff.gz patch, and will
try that. Are there any known bugs in the gcc-core in linuxsh cvs?

Thanks,

Bryan Rittmeyer
mailto:br...@ix...

[linuxsh-dev] gcc problems?

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

Bryan Rittmeyer wrote:
 > gcc: I am using latest gcc-core cvs, checked out around 12:00 PST today.
 > Built exactly according to instructions above. I have also worked with
 > older cvs versions from last week.

I think you mean CVS of our linuxsh of sourceforge.net.  Please note
that Kaz' comment is for GNU's development version, which is not
relevant to sorceforge version, I believe.

 > http://foobar.caltech.edu/linuxsh/sh-ipl-strange.tar.bz2

I got it, and read.  Most importantly, your spec. of bare.mem may be
wring, I guess.  You wrote:

--------------------
MEMORY
{
        ROM (rx):   ORIGIN = 0xA0000000, LENGTH = 16k
        RAM (rw):   ORIGIN = 0xA0004000, LENGTH = 32k
        STACK (rw): ORIGIN = 0xA000C000, LENGTH = 16k
}
--------------------

As far as I know, SuperH cannot have RAM at Area 0 simultaneously with
ROM.  Please double check spec of your board and configuration of
memory specification of other boards.
-- 

Re: [linuxsh-dev] gcc problems?

[Bryan R. <br...@ix...>]

kaz Kojima wrote:

> I'm not sure what is the real problem, but the cvs version of gcc is
> very buggy for SH in this several weeks.
> Now make checking of gcc reports to me several hundred unexpected
> failures. It doesn't bootstrap without some fixes. Please try to get
> the version of around 2000/6/1 with -D option if you prefer cvs version.

That certainly explains a lot. You seem to imply that I can use a
non-cvs version of gcc, even the gcc-2.95.2.tar.gz off of gnu.org?
Initially I thought gcc needed specific updates for the sh architecture,
but after thinking about it more I guess all the SH-specific stuff is
handled by binutils. Right? Now, I am building a sh-linux-gnu-gcc now
using an ordinary gcc-2.95.2 tree, and will try again with that...
hopefully it will fix my problems.

Thanks for the info. Perhaps we should put something in
http://linuxsh.sourceforge.net/docs/building-source.php3 explaining that
the cvs compiler is buggy? I imagine a lot of people new to the project
will use that page as a starting point (like me), and keeping it up to
date with crucial information would be extremely helpful to them (yes, I
am volunteering...)

I definitely should have realized using as little cvs code as possible
would make things easier, but lots of the cvs trees I've worked with
before have almost-release quality code in them most of the time. The
LinuxSH project is still relatively new and I guess that makes the CVS
code a bit more experimental than I assumed.

Cheers,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] gcc problems?

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

Hi,

Bryan Rittmeyer <br...@ix...> wrote:
> gcc: I am using latest gcc-core cvs, checked out around 12:00 PST today.
> Built exactly according to instructions above. I have also worked with
> older cvs versions from last week.

I'm not sure what is the real problem, but the cvs version of gcc is
very buggy for SH in this several weeks.
Now make checking of gcc reports to me several hundred unexpected
failures. It doesn't bootstrap without some fixes. Please try to get
the version of around 2000/6/1 with -D option if you prefer cvs version.

> I would really like to turn optimizations off to debug the assembly
> output, but -O2 is apparently needed for I/O.

I hear that even 2000/6/1 version fails at the gcse optimization
for some sources. In such case, you can use the gcc option like
-O2 -fno-gcse to disable the individual optimization.

	kaz

[linuxsh-dev] gcc problems?

[Bryan R. <br...@ix...>]

Hello linuxsh-dev,

After some more debugging I believe that gcc is producing very odd
assembly output for the sh-ipl stub, which may explain why it is doing
extremely strange things with string handling. Since I have followed all
the directions to the letter, I am quite confused as to what is going on
here... So let me spell out exactly what I've done, and maybe somebody
will be able to repeat my steps or help me get this stuff running.

binutils: I am using
ftp://ftp.m17n.org/pub/linux-sh/binutils-000218.tar.bz2 with
ftp://ftp.m17n.org/pub/linux-sh/bimutils-000218-000519.diff.gz applied
as a patch.
Built exactly according to instructions on
http://linuxsh.sourceforge.net/docs/building-source.php3

gcc: I am using latest gcc-core cvs, checked out around 12:00 PST today.
Built exactly according to instructions above. I have also worked with
older cvs versions from last week.

(In addition to the binutils and gcc used above, I have also tried
everything with the .debs on m17n.org with exactly the same problem).

sh-ipl: I started with sh-ipl+g-2000-08-16.tar.gz using the sesh4
config, then modified the machine/.mem file for my system. I also
modified the config (.h/.mk) slightly to use SCI. Then I changed the
init_bsc routine to correct the frequency control registers for my
system (6:3:1.5) and sh-sci.c to correct the UART multipliers. Even when
those are the only changes I've made, I get a bad sh-stub.bin.
Unfortunately I cannot test one of the precompiled srecs or existing
configurations since I do not have access to any of the supported
boards. But others are working with custom hardware without these
problems...

When using that slightly modified sh-stub, the system comes up with the
menu system and warranty/license viewing works fine. When I enter gdb
stub I get "$#00" (null packet) output to the terminal. In fact, this
null packet is all that is ever output regardless of what I send to it,
although getpacket is apparently evaluating checksums properly.

The problems appear with string handling--getpacket is not inputing
strings correctly, and the putpacket output is always empty. As I
mentioned before, if I change the order in which bytes in the array are
set, I can get the first packet (S05) to output correctly. For example,

  outbuff[1] = highhex(sigval);
  outbuff[0] = 'S';
  outbuff[2] = lowhex(sigval);
  outbuff[3] = 0;

will send a valid string to the terminal when putpacket(outbuff) is
called. However,

  outbuff[0] = 'S';
  outbuff[1] = highhex(sigval); 
  outbuff[2] = lowhex(sigval);
  outbuff[3] = 0;

results in a null packet being output. Needless to say this makes
absolutely no sense. I ran objdump on the elf output, and the assembly
differs by several hundred lines--the only change being the order in
which bytes are set. Again this makes no sense. So I have tarballed up
the code I have been working with and posted it here:

http://foobar.caltech.edu/linuxsh/sh-ipl-strange.tar.bz2

The built elf files are in the /debug directory, with the dumped
assembly output and a diff. Right now the only explanation we have come
up with is a byte alignment issue, but the assembly output might suggest
a lot more is wrong.

I would really like to turn optimizations off to debug the assembly
output, but -O2 is apparently needed for I/O.

If any of you with a working stub get a chance, I would enormously
appreciate it if you took a moment to look at my code and see if your
development environment produces similar results. Debugging is
especially difficult for me since it could be anything from the board
(not likely) to the C code (again not likely) to gcc (right now I think
the obvious culprit is the compiler). But since many people are using
kernels built by the exact same compiler, it can't be very buggy and
should be able to build a small 8k stub OK if it can do an 800k kernel.

It really bothers me that I can't explain what is going on here. As I
said above, any and all help would be appreciated. Maybe I am just doing
something really stupid...

Thanks again for your time.

Regards,

Bryan Rittmeyer
mailto:br...@ca...

[linuxsh-dev] Ptrace works

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

This is the patch.  It works for me.

2000-08-20  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/mm/fault.c (update_mmu_cache): Bug fix.  This routine
	is called by ptrace when PTE does not have information.

Index: arch/sh/mm/fault.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.18
diff -u -p -r1.18 fault.c
--- arch/sh/mm/fault.c	2000/08/12 07:17:48	1.18
+++ arch/sh/mm/fault.c	2000/08/20 01:07:12
@@ -313,6 +313,12 @@ void update_mmu_cache(struct vm_area_str
 	}
 #endif
 
+	/* Ptrace may call this routine. */
+	if (vma && current->active_mm != vma->vm_mm) {
+		restore_flags(flags);
+		return;
+	}
+
 	/* Set PTEH register */
 	pteaddr = (address & MMU_VPN_MASK) | get_asid();
 	ctrl_outl(pteaddr, MMU_PTEH);

Re: [linuxsh-dev] Odd problem

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

NIIBE Yutaka wrote:
 > 	flush_ram_to_page:
 > 	   write back the kernel cache line to the page (D-cache)
 > 	   as well as flush (purge) the cache line (both of user and kernel)

Well this change seems to be needed eventually, as SH-4's cache
is not DMA-coherent, AFAIK.

Besides, it seems for me that flush_cache_page is the one for
virtually tagged cache system.  I'd like to clarify, but now
we don't have VGER...

Here's the patch.  It works fine for me.  Will soon be committed.

Index: arch/sh/mm/cache.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache.c,v
retrieving revision 1.17
diff -u -p -r1.17 cache.c
--- arch/sh/mm/cache.c	2000/08/16 08:34:04	1.17
+++ arch/sh/mm/cache.c	2000/08/19 01:40:11
@@ -358,6 +358,7 @@ void flush_cache_range(struct mm_struct 
  */
 void flush_cache_page(struct vm_area_struct *vma, unsigned long addr)
 {
+#if 0				/* We don't need this... */
 	pgd_t *dir;
 	pmd_t *pmd;
 	pte_t *pte;
@@ -378,11 +379,14 @@ void flush_cache_page(struct vm_area_str
 	phys = pte_val(entry)&PAGE_MASK;
 	pg = virt_to_page(__va(phys));
 	flush_dcache_page(pg);
+#endif
 }
 
 /*
+ * Write-back & invalidate the cache.
+ *
  * After accessing the memory from kernel space (P1-area), we need to 
- * write back the cache line to maintain DMA coherency.
+ * write back the cache line.
  *
  * We search the D-cache to see if we have the entries corresponding to
  * the page, and if found, write back them.
@@ -399,10 +403,8 @@ void flush_page_to_ram(struct page *pg)
 	for (i=0; i<CACHE_OC_NUM_ENTRIES; i++) {
 		addr = CACHE_OC_ADDRESS_ARRAY| (i<<CACHE_OC_ENTRY_SHIFT);
 		data = ctrl_inl(addr);
-		if (((data & (CACHE_UPDATED|CACHE_VALID))
-		     == (CACHE_UPDATED|CACHE_VALID))
-		    && (data&PAGE_MASK) == phys) {
-			data &= ~CACHE_UPDATED;
+		if ((data & CACHE_VALID) && (data&PAGE_MASK) == phys) {
+			data &= ~(CACHE_UPDATED|CACHE_VALID);
 			ctrl_outl(data, addr);
 		}
 	}
Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/mm/memory.c,v
retrieving revision 1.7
diff -u -p -r1.7 memory.c
--- mm/memory.c	2000/08/17 04:27:15	1.7
+++ mm/memory.c	2000/08/19 01:40:33
@@ -790,8 +790,8 @@ static inline void break_cow(struct vm_a
 		pte_t *page_table)
 {
 	copy_cow_page(old_page,new_page,address);
-	flush_dcache_page(new_page);
-	flush_icache_page(vma, new_page);
+	flush_page_to_ram(new_page);
+	flush_cache_page(vma, address);
 	establish_pte(vma, address, page_table, pte_mkwrite(pte_mkdirty(mk_pte(new_page, vma->vm_page_prot))));
 }
 
@@ -1081,7 +1081,7 @@ static int do_swap_page(struct mm_struct
 	} else
 		UnlockPage(page);
 
-	flush_dcache_page(page);
+	flush_page_to_ram(page);
 	flush_icache_page(vma, page);
 	set_pte(page_table, pte);
 	/* No need to invalidate - it was non-present before */
@@ -1106,8 +1106,7 @@ static int do_anonymous_page(struct mm_s
 		clear_user_highpage(page, addr);
 		entry = pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot)));
 		mm->rss++;
-		flush_dcache_page(page);
-		flush_icache_page(vma, page);
+		flush_page_to_ram(page);
 	}
 	set_pte(page_table, entry);
 	/* No need to invalidate - it was non-present before */
@@ -1156,7 +1155,7 @@ static int do_no_page(struct mm_struct *
 	 * so we can make it writable and dirty to avoid having to
 	 * handle that later.
 	 */
-	flush_dcache_page(new_page);
+	flush_page_to_ram(new_page);
 	flush_icache_page(vma, new_page);
 	entry = mk_pte(new_page, vma->vm_page_prot);
 	if (write_access) {
Index: mm/vmscan.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/mm/vmscan.c,v
retrieving revision 1.11
diff -u -p -r1.11 vmscan.c
--- mm/vmscan.c	2000/08/09 12:51:01	1.11
+++ mm/vmscan.c	2000/08/19 01:40:34
@@ -138,6 +138,7 @@ drop_pte:
 	 *
 	 * That would get rid of a lot of problems.
 	 */
+	flush_page_to_ram(page);
 	flush_cache_page(vma, address);
 	if (vma->vm_ops && (swapout = vma->vm_ops->swapout)) {
 		int error;

[linuxsh-dev] Re: [linux-sh:01218] GDB configuration?

[Bryan R. <br...@ix...>]

NIIBE Yutaka wrote:

> Umm... how about setting of reflesh rate of BSC?  Is the RAM stable?
> I have experience that when I had problem of setting BSC, I had seen
> such unexpected error.
> --

I spent several hours last night debugging my system and have found
extremely strange problems with the string handling in the stub code. I
ran through dozens of test cases, slightly modifying the code each time,
and what I've found is basically unexplainable:

* Passing string pointers to functions is either broken, or buggy
* The order in which I set bytes in an array affects the end state of
the array

For example,

if I do something like:

foobuff[0]='F';
foobuff[1]='O';
foobuff[2]='O';
foobuff[3]=0;

Then call putpacket(foobuff) the output string is garbled ("F F" maybe);
however if I set byte 1, then byte 0, then byte 2, then byte 3, the
output is fine ("FOO"). There are other mysterious problems similar to
this, such as all the major string routines being broken (mem2hex, etc).

I can think of just two ways of explaining these problems--a really
buggy, broken compiler (which is not the case, I checked the assembly
output) or a problem with the hardware. Since string handling is the
most memory intensive task in the code I think my problems are just the
result of a nasty misconfigured hardware register. I will go back and
verify all of the BSC settings against our internal boot code and the
Hitachi data sheet and hopefully get things running today.

Thanks to everyone for their help,

Bryan Rittmeyer
mailto:br...@ix...

Re: [linuxsh-dev] Odd problem

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

Hi Stuart, it's really nice to see your info. on:
 > The good news is that I think the cache related problems have been fixed.
 > I'd been looking at this last week, and came to almost exactly the same
 > conclusion about the changes for cache.c and fault.c (I still haven't got
 > the hang of this release early and release often mentality...). What I'd
 > not done is found the problems in memory.c, well done on that.

Nice.  Now the problem is found, I think that it would be better to
maintain the difference between standard kernel and ours as small as
possible, reverting some of my changes.  Possible way is changing
the semantice of flush_ram_to_page of our implementation.

	flush_ram_to_page:
	   write back the kernel cache line to the page (D-cache)
	   as well as flush (purge) the cache line (both of user and kernel)

Then, the important change we need is just one thing, that is, the
change of do_swap_page.  This is real bug.  In the old code, when we
get the page from swap cache, the cache of the page is not flushed.
When the swap cache is read asynchronously, it may causes problem, as
the user stale data may remain on the cache.

Standerd kernel will be changed with flush_dcache_page, which is
introduced recently...  But I'm not sure when such changes will be
done.  So, for a while, I think changing the implementation of
flush_ram_to_page for SuperH would be good (although the name and
functionality is slightly different).

 > Humm, what to do next? Is anyone else looking at gdb/ptrace?

Fixing VGER, now we don't have THE mailing list... ;-)

Currently, I'm not looking ptrace issue.  I'm testing BSC of CqREEK
SH-4, for ISA Bus and IDE...  So far, so bad.  It's good for me to
have different implementations of SH-4.  At the first CqREEK was
stable, while SolutionEngine SH-4 was not.  Now with the ISA/IDE
bridge, CqREEK SH-4 is unstable.  I can see the difference of two
board, that's good thing.

Besides, when/if you think the directory sh/overdrive is ready or
worth to inclusion of standard kernel, just say so.  When I'll send
next update to Linus, I'll include that part.
-- 

Re: [linuxsh-dev] Odd problem

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

Folks

OK, so I was being a complete wally. Having tracked it right down to
a problem writing the data to the IDE controller, and made it work
reliably by adding 'hda=slow' to the command line, Dave spotted that I
was using the wrong BSC initialisation values, and running the memory
interface to the PCI controller too fast. Oh well, at least I leared
something about IDE interfaces I suppose... Sorry everyone.

The good news is that I think the cache related problems have been fixed.
I'd been looking at this last week, and came to almost exactly the same
conclusion about the changes for cache.c and fault.c (I still haven't got
the hang of this release early and release often mentality...). What I'd
not done is found the problems in memory.c, well done on that.

My test program, which was four parallel compiles (-O2 and -pipe), on
a machine with 4M RAM, has been running for 12 hours now, with no problems.

Humm, what to do next? Is anyone else looking at gdb/ptrace?

Stuart

Re: [linuxsh-dev] Ptrace

[Greg B. <gn...@al...>]

>On Aug 16,  2:01am, mj...@al... wrote:
>> Subject: Re: [linuxsh-dev] Ptrace
>>
>> David Mckay wrote:
>> >
>> > Hi,
>> >
>> > Is anybody doing any work on ptrace and strace?
>>
>> Hi David,
>>
>> Just a heads-up, Greg is working on the strace usermode
>> program at the moment.  It's quite funny - as he goes
>> through the existing source code, he groans and mutters.
>> It's pretty bad code, I think it could be used to frighten
>> small children.

  I'd say it's a dog's breakfast but that would insult dogs.

>
>He is obviously a lot braver than me. I started looking at that stuff and
>rapidly put it on my list marked "Things I hope somebody else does before
>I have to" :-)

  I volunteered because I'd had previous exposure to strace
when I wrote autodep
(http://freshmeat.net/appindex/1999/05/07/926058334.html)
which uses algorithms stolen from strace (and completely
rewritten for legibility).  However not only had I
forgotten how bad it was, but in the meanwhile it had
gained linux-mips, linux-arm and linux-s390 ports, all
adding extra layers of cruft.

Greg.
http://www.alphalink.com.au/

Re: [linuxsh-dev] Ptrace

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

David Mckay wrote:
> 
> > Just a heads-up, Greg is working on the strace usermode
> > program at the moment.
>
> He is obviously a lot braver than me. I started looking at that stuff and
> rapidly put it on my list marked "Things I hope somebody else does before
> I have to" :-)

I'm finding it quite fun.  Listening to Greg as he tears his
hair out, that is!  There are many fundamental bad things about
it.  Greg is trying to do minimum SuperH changes, while resisting
the temptation to fix all the obviously sub-optimal cruft in it,
at least until after the SuperH patch has gone in.

> As an aside, we now have an engineer working full time on producing a
> distribution. It will be based on Montavista's distribution

A good choice, for the reasons Stuart mentioned earlier.

> The guy who is doing it is
> a Linux novice, so it may take some time for him to get up to speed.

I am very interested in helping with this task.  If there's anything
I can do, please yell.

> Just out of curiosity, how many other people on the list are actually paid to
> work full time on Linux for SuperH? We now have 3 here at ST.

Oh excellent.  Yes, Greg and I are.  But forces beyond our control
meant we couldn't start until Monday of this week.

Regards,

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

Re: [linuxsh-dev] GDB configuration?

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

Bryan Rittmeyer wrote:
> 
> I have been lurking on this list for a couple days

Welcome Bryan!

> kernel running. However, for some reason, the GDB on my
> workstation just does not want to talk to the embedded board.

It's not possible to use just any version of gdb, nor an arbitrary
version compiled for the SuperH.  The definitive version of GDB
that you should use is stored in CVS on SourceForge.

> I have experimented with as
> many versions of the boot/stub as I could find, including the one on
> sourceforge CVS (which has some rather broken code in places),

I briefly experimented with checking an earlier version of
Niibe-san's gdb-sh-stub into CVS on SourceForge, but he changed
the name and layout of the stub/loader to sh-ipl-g, so I
abandoned it.  So I would not recommend getting the stub/loader
from here.

Instead I would go to Niibe-san's site, here:

  ftp://ftp.m17n.org/pub/super-h/

> I now believe the problem is now with the GDB on the
> workstation 

Please note there's a definite sequence of commands you
must type to connect gdb on the host to the stub on the target.
Look for ".gdbinit-sesh4" in the top-level of the Linux kernel
source.  The first few commands are those necessary to
establish a connection.

> since it looks like
> there are three forks of the same code (CVS sh-boot, gdb-sh-stub, and
> sh-ipl+g).

Use sh-ipl+g.  The rest are older.

> I am assuming it is possible to load a kernel into an arbitrary memory
> location (over the serial port) once GDB and the SH4 stub are talking?

We (Greg and I) compile our kernel with "make ARCH=sh vmlinux".  This
is an ELF file which contains the start address of the kernel.
When you transfer this file to the target, gdb uses the embedded
ELF information to send it to the right location.

If you wanted it to run at an alternative location, you should
modify the linker script.  If you wanted it to run at the standard
location but be loaded into an alternate place (maybe your boot
code will copy it into the right place) you should look into
the ": AT ()" linker directive in the linker script.  This will
cause the kernel to be linked to run at one address, but GDB
will load it at another.

Regards,

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