linuxsh-dev

[linuxsh-dev] pvr2fb changes in 2.4.10

[M. R. B. <mr...@0x...>]

Uh, did the following changes come from mainline?  The fb_find_mode()
portion was discussed already, and it's wrong so I'm backing it out.

I hope we aren't sneaking subtle changes in and not logging/posting them.
Especially if it's in code that doesn't belong to you...

Thanks,

M. R.


--- linux-sh-dc/drivers/video/pvr2fb.c	Sat Sep 29 21:50:26 2001
+++ /home/mrbrown/src/cvs/sh/kernel/drivers/video/pvr2fb.c	Mon Oct  1 00:58:15 2001
@@ -51,7 +51,7 @@
 #include <linux/string.h>
 #include <linux/mm.h>
 #include <linux/tty.h>
-#include <linux/malloc.h>
+#include <linux/slab.h>
 #include <linux/delay.h>
 #include <linux/config.h>
 #include <linux/interrupt.h>
@@ -299,7 +299,7 @@
 #define DEFMODE_VGA	2
 
 static int defmode = DEFMODE_NTSC;
-static const char *mode_option __initdata = NULL;
+static char *mode_option __initdata = NULL;
 
 /* Get the fixed part of the display */
 
@@ -1047,7 +1047,7 @@
 		defmode = DEFMODE_VGA;
 
 	if (!fb_find_mode(&var, &fb_info, mode_option, pvr2_modedb,
-	                  NUM_TOTAL_MODES, &pvr2_modedb[defmode], 16)) {
+	                  NUM_TOTAL_MODES, &pvr2_modedb[defmode], 32)) {
 		return -EINVAL;
 	}
 
@@ -1166,6 +1166,7 @@
 #endif
 
 #ifdef MODULE
+MODULE_LICENSE("GPL");
 module_init(pvr2fb_init);
 #endif
 module_exit(pvr2fb_exit);

[linuxsh-dev] GCC 3.0.1 compiler seg fault

[Dustin M. <du...@se...>]

I've just started using gcc-3.0.1 to build the 2.4.10 kernel, but when I add
the cs4281 sound module to the build I get a compiler seg fault. Can anyone
else reproduce this?  The cs4281 device is found under "Sound-->Crystal
Sound CS4281" in the config script.

Dustin.

sh4-linux-gcc -D__KERNEL__ -I/home/dustin/mgate/software/core/kernel/include
 -Wa
ll -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-a
lias
ing -fno-common -ml -m4-nofpu -pipe -DMODULE    -c -o cs4281m.o cs4281m.c
cs4281m.c: In function `cs_printioctl':
cs4281m.c:513: Internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

[linuxsh-dev] Joypad support on Dreamcast

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

I've put root file system image of Dreamcast for my presentation
at Linux Conference 2001 (Japan).
	ftp://ftp.m17n.org/pub/super-h/testing/dc-010927.tar.gz

Login as "guest" with no password, then, 
	$ dfbpoint fg.xml

shows the presentation (in Japanese).

I did the presentation, been asked the copy of CD-R, and found that
many don't have keyboard for Dreamcast.

Isn't it a good idea to implement special terminal discipline featured
for joypad?  I mean, it would be good if we can use Dreamcast Linux
only with joypad.  Analog joystick could be used as mouse.
-- 

[linuxsh-dev] Changes for 2.4.10

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

Added __put_user_u64 and inclusion of <linux/personality.h>.
I'll commit this change with 2.4.10.

Index: include/asm-sh/uaccess.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/uaccess.h,v
retrieving revision 1.12
diff -u -r1.12 uaccess.h
--- include/asm-sh/uaccess.h	2001/07/27 06:09:47	1.12
+++ include/asm-sh/uaccess.h	2001/10/01 01:51:18
@@ -150,6 +150,7 @@
 case 1: __put_user_asm("b"); break; \
 case 2: __put_user_asm("w"); break; \
 case 4: __put_user_asm("l"); break; \
+case 8: __put_user_u64(__pu_val,__pu_addr,__pu_err); break; \
 default: __put_user_unknown(); break; \
 } __pu_err; })
 
@@ -165,6 +166,7 @@
 case 1: __put_user_asm("b"); break; \
 case 2: __put_user_asm("w"); break; \
 case 4: __put_user_asm("l"); break; \
+case 8: __put_user_u64(__pu_val,__pu_addr,__pu_err); break; \
 default: __put_user_unknown(); break; \
 } } __pu_err; })
 
@@ -189,6 +191,53 @@
 	:"=&r" (__pu_err) \
 	:"r" (__pu_val), "m" (__m(__pu_addr)), "i" (-EFAULT) \
         :"memory"); })
+
+#if defined(__LITTLE_ENDIAN__)
+#define __put_user_u64(val,addr,retval) \
+({ \
+__asm__ __volatile__( \
+	"1:\n\t" \
+	"mov.l	%R1,%2\n\t" \
+	"mov.l	%S1,%T2\n\t" \
+	"mov	#0,%0\n" \
+	"2:\n" \
+	".section	.fixup,\"ax\"\n" \
+	"3:\n\t" \
+	"nop\n\t" \
+	"mov.l	4f,%0\n\t" \
+	"jmp	@%0\n\t" \
+	" mov	%3,%0\n" \
+	"4:	.long	2b\n\t" \
+	".previous\n" \
+	".section	__ex_table,\"a\"\n\t" \
+	".long	1b, 3b\n\t" \
+	".previous" \
+	: "=r" (retval) \
+	: "r" (val), "m" (__m(addr)), "i" (-EFAULT) \
+        : "memory"); })
+#else
+({ \
+__asm__ __volatile__( \
+	"1:\n\t" \
+	"mov.l	%S1,%2\n\t" \
+	"mov.l	%R1,%T2\n\t" \
+	"mov	#0,%0\n" \
+	"2:\n" \
+	".section	.fixup,\"ax\"\n" \
+	"3:\n\t" \
+	"nop\n\t" \
+	"mov.l	4f,%0\n\t" \
+	"jmp	@%0\n\t" \
+	" mov	%3,%0\n" \
+	"4:	.long	2b\n\t" \
+	".previous\n" \
+	".section	__ex_table,\"a\"\n\t" \
+	".long	1b, 3b\n\t" \
+	".previous" \
+	: "=r" (retval) \
+	: "r" (val), "m" (__m(addr)), "i" (-EFAULT) \
+        : "memory"); })
+#endif
 
 extern void __put_user_unknown(void);
 
Index: arch/sh/kernel/signal.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/signal.c,v
retrieving revision 1.15
diff -u -r1.15 signal.c
--- arch/sh/kernel/signal.c	2001/01/29 00:39:12	1.15
+++ arch/sh/kernel/signal.c	2001/10/01 01:49:24
@@ -21,6 +21,7 @@
 #include <linux/ptrace.h>
 #include <linux/unistd.h>
 #include <linux/stddef.h>
+#include <linux/personality.h>
 #include <asm/ucontext.h>
 #include <asm/uaccess.h>
 #include <asm/pgtable.h>
-- 

Re: [linuxsh-dev] Crashme!!!

[M. R. B. <mr...@0x...>]

* Bao C. Ha <ba...@se...> on Wed, Sep 26, 2001:

> 
> Appreciate is someone running it to see it it passes or fails
> on other sh4-based systems.
> 

Just for kicks, I ran crashme on my Dreamcast with the example parameters
listed in the manpage.  I'm running under kernel 2.4.10-pre6.  No problems
whatsoever.  You may want to look for another means of finding your problem.

-->
root@blackbox:~/crashme# ./crashme
crashme [+]<nbytes>[.inc] <srand> <ntrys> [nsub] [verbose]
root@blackbox:~/crashme# ./crashme +2000 666 100 1:00:00
Crashme: (c) Copyright 1990-1994 George J. Carrette
Version: 2.4 20-MAY-1994
crashme +2000 666 100 1:00:00
Subprocess run for 3600 seconds (0 01:00:00)
pid = 185 0xB9 (subprocess 1)

[tons of useless output deleted]

Subprocess 446: try 24, Badboy at 4319792. 0x41EA30
time limit reached on pid 1347 0x543. using kill.
pid 1347 0x543 exited with status 9
Time limit reached after run 446
Test complete, total real time: 3619 seconds (0 01:00:19)
exit status ... number of cases
        256 ...     7
	  9 ...    19
	 11 ...   420
root@blackbox:~/crashme#
root@blackbox:~/crashme# uname -a
Linux blackbox 2.4.10-pre6 #9 Sun Sep 23 20:57:42 CDT 2001 sh4 unknown
root@blackbox:~/crashme#

> Thanks.
> Bao

M. R.

[linuxsh-dev] Crashme!!!

[Bao C. H. <ba...@se...>]

I ran a small program called crashme to test our sh4-based
system.  It crashes kernel 2.4.8 in less than 5 minutes.
The system is completely lockup without any error messages.

I ran it again on the Hitachi Bigsur (SH7751) with kernel 
2.4.3.  It caused a kernel panic after running for more than
30 minutes with the following message:
....
kernel BUG at fpu.c:240!
illegal slot instruction: 01a0

PC  : fc000652 SP  : 7bfffb00 SR  : 70000001 TEA : 70000389
R0  : 0000000a R1  : 004164e0 R2  : fffffff4 R3  : 0000001b
R4  : 0000000a R5  : 7bfff934 R6  : 0011c5f4 R7  : 00000118
R8  : 00004b1e R9  : 00000788 R10 : 00400840 R11 : 004164e7
R12 : 00000011 R13 : 4b8e6c60 R14 : 7bfffb00
MACH: 00000003 MACL: 0007443d GBR : ef7e7ffb PR  : 004015f6
Killing process "crashme" due to unaligned access
Killing process "bash" due to unaligned access
unaligned program counter: 00e0

PC  : ffffffff SP  : 8c91ff3c SR  : 40008000 TEA : ffffffff
R0  : 400080f1 R1  : 8c160720 R2  : c0042d8c R3  : 000000a8
R4  : 00000001 R5  : 8c16e600 R6  : 00000003 R7  : 8c1601dc
R8  : 00000001 R9  : 00000001 R10 : 8c16e600 R11 : 00000000
R12 : 8c159fa0 R13 : fffffffe R14 : 7bfff924
MACH: 00000033 MACL: 000000c0 GBR : ef7e7ffb PR  : 8c01a02a
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
....

I have attached the crashme.tgz here if anybody wants to try
it.  I think there is a memory problem, and would like to
isolate it to either our hardware or the kernel.

The purpose of crashme is to test the  operating environment's 
robustness  by  invoking random data as if it were a procedure.
The standard signals are caught and  handled  with  a  setjmp 
back to a loop which will try again to produce a fault by 
executing random data.

Appreciate is someone running it to see it it passes or fails
on other sh4-based systems.

Thanks.
Bao

Re: [linuxsh-dev] Next change

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

More explanation of .hidden.

Problem:
    With the call through PLT (Procedure Linkage Table), 
    (unexpected) register(s) will be clobbered.

There're two cases, one is (non-PIC) executable, and another is (PIC)
shared library.

Case 1: Executable
Suppose an executable is linked to a shared library which exports a
libgcc function.  At link time, PLT will be generated and the call to
that libgcc function will become the one through PLT.

To prevent this, a solution would be using .hidden for libgcc
functions.


Case 2: Shared library
Normal pc-relative call has no problem.

There're cases of call of libgcc functions, using the symbol reference
through GOT (Global Offset Table) which goes through PLT.  Like this:
----------------------
    <<CALL of __udivsi3>>
	mov.l	.L1,r0
	mov.l	@(r0,r12),r1
	jsr	@r1
	 nop
	...
.L1:
	__udivsi3@GOT

GOT:
	...
__udivsi3@GOT:
	The address of PLT entry of __udivsi3

PLT:
	...
	opecode of PLT 
	...
	Offset of __udivsi3 
----------------------

When we use .hidden attribute for the libgcc function (in this case,
__udivsi3), PLT will not be generated and it will become like that
(at link time):
----------------------
    <<CALL of __udivsi3>>
	mov.l	.L1,r0
	mov.l	@(r0,r12),r1
	jsr	@r1
	 nop
	...
.L1:
	__udivsi3@GOTOFF
----------------------
-- 

[linuxsh-dev] Re: [linux-sh:01947] Re: SH-3 MMU Bug

[M. R. B. <mr...@0x...>]

* ebihara <ebi...@si...> on Sat, Sep 22, 2001:

> 
> Please commit your nice work.
> 
> 
> diff -urN kernel/arch/sh/config.in kernel.tmp/arch/sh/config.in
> --- kernel/arch/sh/config.in	Sat Sep 22 18:54:11 2001
> +++ kernel.tmp/arch/sh/config.in	Sat Sep 22 19:34:24 2001
> @@ -115,6 +115,9 @@
>     hex 'Physical memory start address' CONFIG_MEMORY_START 08000000
>     hex 'Physical memory size' CONFIG_MEMORY_SIZE 00400000
>  fi
> +if [ "$CONFIG_CPU_SH3" = "y" ]; then
> +   bool "SH3 mmu sharedbit bug workaround" CONFIG_SH_SH3_MMU_BUG_WORKAROUND
> +fi
>  endmenu
>  

Hmm, if this is a bug across all SH3's, then why is a config option
required?  The port distinguishes across chip numbers, so if anything, if
it's localized to say, the SH7709, then you should workaround that, but
don't add a new config option for something so trivial.

M. R.

[linuxsh-dev] Re: Next change

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

kaz Kojima wrote:
 > So, I think the remained patchs are:
 > 
 >   All configury patches
 >   Niibe-san's patches to fix branch slot fill
 >   patch to make libgcc asm functions hidden
 > 
 > at least, for 3.0-branch.

As I did explain hidden.  I explain other two.

Configury patches is for support of specific targets, sh3, sh4, sh3eb,
and sh4eb.  To test it, I did the Debian bootstrap, which includes
initial cross compiler build, next cross compiler build, and native
compiler build by cross compiler.  I think it works.
Besides, GCC build don't have support of:
	 compile time multilib but not runtime multilib
which should be solved.  Current patch is obviously Wrong Thing.

My patch to fix branch slot fill is Wrong Thing too.  It just works
around by changing the length of branch 6 to 8.  Real fix should be
elsewhare but I couldn't find where is the cause.
-- 

[linuxsh-dev] Re: Next change

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

"M. R. Brown" <mr...@0x...> wrote:
> I and others have always been confused by the "hidden" patch.  What does it
> do?  Why is it required?  I've build glibc without it, so it isn't required
> for that build step - what other reasons are there?

It's an old story but I can't find the old messages in
linux-sh archive about it. So I'd like to show you an example.

Write a function f() which uses unsigned integer divisions
in SH4 and make it a shared library, say libfoo.so. Also write
a program bar using unsigned integer divisions and f(). Link
them so that the linker finds libfoo.so before libgcc.a.

Look bar closely. It'll call __udivsi3_i4 in libfoo.so via
PLT. If you read gcc/config/sh/sh.md, you see that gcc will
suppose that the call of this function doesn't clobber R2
which will clobber by PLT. If your bar program is complex
enough, then there is a case which register R2 is a live
resister when calling __udivsi3_i4.
Of course, you might be lucky and not hit by this problem
if you don't use shared libraries heavily :-)

If this function symbol is hidden, libfoo.so doesn't export
this function and the linker find it from libgcc.a and non-PLT
call is used.
So we need hidden patch or patch for sh.md to add additional
clobber informations. Our old PIC patch for sh.md had this,
but that part was removed. And we (at least, I) misunderstood
this problem disappeared in the new implementation of PIC by
Cygnus.

As I wrote in previous mail, the big lib1asmfunc patch was
waiting to be committed. I think it's a good chance to send
hidden patch or patch for sh.md again. Anyway, without this
lib1asmfunc patch, we can handle only toy use of the shared
libraries. 

> Hopefully the work done by MontaVista and kaz's continual patch submission
> can help get us there.

About GCC, merging sh-linux local patches to the mainline isn't
so easy as you imagine, I think. Even if our patch is not so
bad, there are many solutions and plans by other people.
In such case, our patch may not be approved.
Moreover, our local patches tend to be "work for me" patches
without the clear explanation and testcase. To merge such
patches to the mainline should not be approved. I think this
way is reasonable. OTOH, sometimes, I couldn't make even clear
testcases for some local patchs.
Please do such things by yourself also. Our local patches are
free - everyone can test them. We've always responded to "what
is this patch?". There is no reason to wait someone's slow and
limited work :-) Many tests will hit a good testcase and the real
cause of problem. No one can stop you to send the complete patch
to the mainline.

	kaz

Re: [linuxsh-dev] Next change

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

I agree that we should not diverge the GCC.  My point is the one I've
used is not 3.0.1 for the record.  I don't recommend to diverge or
fork too.

I did let people know whole Debian system (for bootstrap) now can be
done with 3.0.1 (with small patches).  Not long ago, we rely on
unreleased GCC.  I think that this is good move toward the goal.

M. R. Brown wrote:
 > I and others have always been confused by the "hidden" patch.  What does it
 > do?  Why is it required?  I've build glibc without it, so it isn't required
 > for that build step - what other reasons are there?

I have explained several times about it here, and I thought that its
purpose is clear.  Umm... it was two yeas ago or a year ago.

Well, I explain it again, because I have update on that.  Sharing idea
and experience is good thing.  This time, I only explain about current
patch, not the history (which is complicated).

			*	*	*

GCC emits some external functions, which are implemented in libgcc.
There's two cases for the emits.  One is as usual function call,
and another is special call which may not follow the calling
convention (of clobbering register).

Without .hidden, libgcc call may become PLT call for shared library.
(PLT call is the hook of dynamically link the code)

For usual function call, it's OK, GCC knows everything which register
will be clobbered.  Another case, some register (for use of PLT call)
will be clobbered unexpectedly, this is a problem.  The code GCC emits
does not expect the register for PLT call will be clobbered.

Well, this is my understanding and explanation.

I think that the use of .hidden in this case is just a implementation.
It could be solved by another way.  Perhaps, distingushing libgcc call
and don't allow PLT call for that.  I'm not sure for that implementation, 
but it would be worth considering...
-- 

Re: [linuxsh-dev] Next change

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Sep 21, 2001:

> M. R. Brown wrote:
>  > Actually gcc 3.0.1 (latest official release) can bootstrap and build
>  > sh-linux.  It doesn't have the target specific "no multilib" support, so you
>  > can't build sh4-linux, but it still works without patches.  When I started
>  > working on an alternative to the current multilib scheme (i.e. completely
>  > disabling mulitlibs for the generic sh-linux target), I tested gcc 3.0.1
>  > *without* kaz's patches, and I was able to build and boot kernels just
>  > fine.
> 
> I've re-read the diff of gcc-sh-linux package.  I think that for use
> of shared library, the change of libgcc.a (of hidden) is required, at
> least.
> 

I and others have always been confused by the "hidden" patch.  What does it
do?  Why is it required?  I've build glibc without it, so it isn't required
for that build step - what other reasons are there?

> My point is, I don't think it is minimum set of patches, but it is OK
> for Debian bootstrap.  3.0.1 is not OK for whole build.
> 

If Debian wants to make that divergence and they support you, then cool (I
guess), but I speak for a few SH developers (not just sh-linux) that would
like to see mainline be *the* SH toolkit, and not rely on a fork (think
about it, if it were sanctioned by gcc it'd be it's own branch) to get
things done.

Hopefully the work done by MontaVista and kaz's continual patch submission
can help get us there.

M. R.

[linuxsh-dev] Re: Next change

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

NIIBE Yutaka <gn...@m1...> wrote:
> I'll re-evaluate each part of patches if those are really required or
> not.

I don't know about 3.0.1-relase well but there are some patches for
3.0 which aren't needed for 3.0-branch. The aims of patches for

  gcc/config/sh/libgcc-std.ver
  gcc/config/sh/sh.h
  gcc/config/sh/sh.c (except for Niibe-san's pathes)
  gcc/except.c (except for patches to sjlj_mark_call_sites)

are done by another fixes. The patch for gcc/sibcall.c are needed
only for c++ and java exception handling. (GCC people said that
these would be unnecessary. I'm waiting.)
I don't know that the patch for gcc/flow.c(insn_dead_p) is needed
or not for 3.0-branch. This was required to build XFree86 but is
a kind of "work for me" patch and not the Right Thing.
The patch for gcc/config/sh/lib1funcs.asm (minus hidden) was already
sent to gcc-patches mailing list by gcc guy of RedHat though not yet
commited. So, I think the remained patchs are:

  All configury patches
  Niibe-san's patches to fix branch slot fill
  patch to make libgcc asm functions hidden

at least, for 3.0-branch.

	kaz

Re: [linuxsh-dev] Next change

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

M. R. Brown wrote:
 > Actually gcc 3.0.1 (latest official release) can bootstrap and build
 > sh-linux.  It doesn't have the target specific "no multilib" support, so you
 > can't build sh4-linux, but it still works without patches.  When I started
 > working on an alternative to the current multilib scheme (i.e. completely
 > disabling mulitlibs for the generic sh-linux target), I tested gcc 3.0.1
 > *without* kaz's patches, and I was able to build and boot kernels just
 > fine.

I've re-read the diff of gcc-sh-linux package.  I think that for use
of shared library, the change of libgcc.a (of hidden) is required, at
least.

My point is, I don't think it is minimum set of patches, but it is OK
for Debian bootstrap.  3.0.1 is not OK for whole build.

I'll re-evaluate each part of patches if those are really required or
not.
-- 

Re: [linuxsh-dev] Next change

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

M. R. Brown wrote:
 > Actually gcc 3.0.1 (latest official release) can bootstrap and build
 > sh-linux.  It doesn't have the target specific "no multilib" support, so you
 > can't build sh4-linux, but it still works without patches.  When I started
 > working on an alternative to the current multilib scheme (i.e. completely
 > disabling mulitlibs for the generic sh-linux target), I tested gcc 3.0.1
 > *without* kaz's patches, and I was able to build and boot kernels just
 > fine.

Thanks much for the information.  I didn't know that.  

Kaz's work has been against mainline, and at the time of 3.0, he
kindly backported his work to 3.0.  And at that time of 3.0, the patch
was surely needed.  I just take his patch and apply to 3.0.1.  It's my
fault not examine the changes of 3.0.1 and just blindly apply his
patch to package Debian gcc-sh-linux.  I'll try to package fewer patches
next time.

So, highest priority would be the patch of target specific "no multilib"
support, isn't it?
-- 

Re: [linuxsh-dev] Next change

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

M. R. Brown wrote:
 > Why is this necessary?

For kernel, it would be OK to use 2.95.x with some fixes and support
of -mno-fdiv-divsi.  But it's not the clean 2.95.x anyway, and we don't
have such compiler.

Currently we need patched comipler.  I think that it would be good
if we don't need any patches to GCC, and we should keep the patches
as small as possible, but we need the patches for now.

I mean, there's not any useful compiler other than 2.96 snapshot with
patches or 3.0 with patches.

I continue to send changes to Kaz, well, to mainline development for
inclusion.

 > IIRC the mainline kernel is geared towards gcc-2.95.2,

Weird.  I believe that many developpers use newer compiler with
__builtin_expect, which is not supported in 2.95.  Perhaps, 
it is because RedHat ships kgcc?
-- 

Re: [linuxsh-dev] stable SH4 environment

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

Stuart Menefy wrote:
 > I've been looking at the compiler you used to build the debian
 > environment, and am rather confused (not that that is hard, I must
 > admit).
 > 
 > It appears to build the kernel using gcc 3.0.1, but then later in the
 > build replaces it with gcc 3.0 + a massive patch to build everything else.
 > 
 > I thought from the posting a couple of days ago 3.0.1 was now ready
 > for use, or are there still problems?

No problem.  (It's Debian specific issue.)

There's three builds of GCC in the bootstrap.
	(1) Initial cross GCC with static libgcc.
	(2) cross GCC with shared libgcc.
	(3) native GCC.

For (1) and (2), I use my own package (gcc-sh-linux).  For (3) I took
the package from Debian pool and added SuperH specific patch.

Yes, (3) includes massive patches which Debian guy has done, but I
don't rely on them.

The initial compiler #1 is replaced by compiler #2.  Note that the
source code base is same for #1 and #2.  The difference is configure
process and required library.  To build #2 compiler, we need C
library.  To build C library, we need a compiler, that's #1 compiler.

Then, (only) shared libgcc is replaced by the one of #3.  Note that
cross compiler is not replaced.  This is needed for Debian because of
package dependency.  Package which depends on shared libgcc should
have package dependency to the package "libgcc1", not to the cross
compiler package.

			*	*	*

Here's the steps I've done.

Step 0:
Build and install dpkg (modified to support all SuperH targets), 
dpkg-cross (modified to support all SuperH targets). 

I need the modification because it doesn't support all SuperH targets.
Besides, SuperH development environment is somewhat special.  GCC for
sh-linux is multilibbed environment and supports all of targets, i.e.,
sh3-linux, sh4-linux, sh3eb-linux, and sh4eb-linux.

Step 1.0:
Build and install binutils-sh-linux which supports sh-linux (all of
SuperH target), optionally build and install gdb-sh-linux.
Ideally, we don't need those two.  However, we need it for now
because
	We have a local patches not integrated into mainline binutils
	and gdb
	We need special setting to support all of
	  sh3-linux, sh4-linux, sh3eb-linux, and sh4eb-linux
	with sh-linux target.

Step 1.1:
Build and install initail gcc for sh-linux.  As we don't have working
glibc at this point, we only could build gcc with static libgcc.

Step 1.2:
Prepare kernel headers.

Step 1.3:
Build and install glibc.

Step 1.4:
Build and install cross compiler, gcc-sh-linux.  (We need this special
package for now, which shoud be integrated to standard gcc package.)

Step 1.5:
Build native compiler with cross compiler.  We get working (shared)
libgcc package in this build.  Remove libgcc of 1.4, install libgcc.

Step 2.0:
Build and install libraries.

Step 2.1:
Build and install libraries (which depends 2.0).  pam, procps, and
readline.

Step 3.0:
Build basic packages.

Step 3.1:
Build basic packages for Debian.

Step 3.2:
Build development packages.

Step 3.3:
Build development packages for Debian.

Step 3.4:
Build optional packages.  gdb, groff and ntp...

Step 4.0:
With native system, build perl.

Step 5.0:
With native system, build the package perl, libnet-perl, expect, and
dejagnu.  (Those packages cannot be build on cross environment easily.)


Step 4.0 is a kind of black magic.  Well, I've heard that the cross
compilation is planned in 5.7 of perl.  If we could cross compile
perl, we can bootstrap cleanly.
-- 

Re: [linuxsh-dev] Next change

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Wed, Sep 19, 2001:

> As the kernel is reasonably stable, I won't do any change for a week or so.
> 
> Then, I'll do:
>    (1) Migrate to GCC 3.0.  Assume GCC 3.0 for compiling.
>        I mean, I'll commit the changes of Makefile of -mno-fdiv-divsi.
> 

Why is this necessary?  IIRC the mainline kernel is geared towards
gcc-2.95.2, and although the 2.95.x series isn't stable for the SH, 3.x
isn't all that better (it's stable but there are still a lot of unpatched
bugs).  Are you relying on the fact that people are only going to build the
kernel with kaz's patched gcc?  AFAIK -mno-fdiv-divsi isn't in gcc CVS and
it definitely wasn't in gcc 3.0, so it seems like you're "migrating" to gcc
CVS + kaz's patches - hopefully everyone's aware of this.

M. R.

Re: [linuxsh-dev] stable SH4 environment

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

Niibe-san

I've been looking at the compiler you used to build the debian
environment, and am rather confused (not that that is hard, I must
admit).

It appears to build the kernel using gcc 3.0.1, but then later in the
build replaces it with gcc 3.0 + a massive patch to build everything else.

I thought from the posting a couple of days ago 3.0.1 was now ready
for use, or are there still problems?

Thanks

Stuart


On Sep 19, 10:07pm, gn...@m1... wrote:
> Subject: [linuxsh-dev] stable SH4 environment
> I've put my work at:
> 	ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010919/
> 
> There's source tar.gz and diff.gz and result .deb(s).  The total size
> is about 620MB.
> 
> This is a kind of record to build Debian GNU/Linux on SuperH from
> scratch.  I put the work there so that we can share the experience.
> My goal was build four systems (sh3, sh4, sh3eb, and sh4eb) which are
> able to boot strap.  I mean, the system with enough develeopment
> environment.
> 
> BTW, I've joined <deb...@li...> last week. 
> -- 
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 
> 
>-- End of excerpt from gn...@m1...

[linuxsh-dev] Next change

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

As the kernel is reasonably stable, I won't do any change for a week or so.

Then, I'll do:
   (1) Migrate to GCC 3.0.  Assume GCC 3.0 for compiling.
       I mean, I'll commit the changes of Makefile of -mno-fdiv-divsi.

   (2) Removal of FPU hack.

   (3) Sync to mainline.  You know, 2.4.10 will include much changes
       on VM subsystem...
-- 

[linuxsh-dev] stable SH4 environment

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

I've put my work at:
	ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010919/

There's source tar.gz and diff.gz and result .deb(s).  The total size
is about 620MB.

This is a kind of record to build Debian GNU/Linux on SuperH from
scratch.  I put the work there so that we can share the experience.
My goal was build four systems (sh3, sh4, sh3eb, and sh4eb) which are
able to boot strap.  I mean, the system with enough develeopment
environment.

BTW, I've joined <deb...@li...> last week. 
-- 

[linuxsh-dev] SolutionEngine 7751 problem

[Oscar G. <osc...@up...>]

hi!!!

I=B4ve got a little problem with trying to boot the kernel in my
SolutionEngine 7751 with hard drive...

I receive a message of lost interrupt when the kernel is trying to find t=
he
partitions in the hard drive and from here, to end, until I receive the
message of kernel panic...

I tried to compile the kernel with DMA or PIO modes enabled for hard driv=
e,
but in both cases the kernel doesn't work well...

i don't know if is a problem in the ipl or something in the kernel...

the hard drive I use is a Fujitsu of 6 GB...

is any problem with the registers of the M1543C B1 or the PCI init or
anything like this???

can anybody help me???

thank you...

[linuxsh-dev] ASPEN/TAHOE Board

[Yuankang L. <yk...@hf...>]

SGksYWxsDQoNCiAgICBJIGFtIGEgbmV3YmllIGZvciBsaW51eC9zaCBhbmQgU0h4IHByb2Nlc3Nv
ci4NCiAgICBOb3cgSSBoYXZlIGEgQVNQRU4vVEFIT0UgQm9hcmQuIElzIHRoZXJlIGFueWJvZHkg
cnVuIGxpbnV4IG9uIHRoaXMgYm9hcmQgPw0KICAgIFdoZW4gSSBtYWtlIHRoZSBrZXJuZWwsIEkg
Y291bGRuJ3QgZmluZCB0aGUgQVNQRU4vVEFIT0UgYm9hcmQgaW4gU3VwZXJIIHN5c3RlbSB0eXBl
Lg0KICAgIERvZXMgdGhlIGtlcm5lbCBub3Qgc3VwcG9ydCBBU1BFTi9UQUhPRSBib2FyZCBub3c/
DQogICAgV2hhdCBhcmUgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gQVNQRU4vVEFIT0UgYm9hcmQg
YW5kIFNvbHV0aW9uRW5naW5lID8NCiAgICANCiAgICBUaGFua3MgZm9yIHlvdXIgaGVscCENCg0K
DQpSZWdhcmRzLA0KDQpZdWFua2FuZyBMZWUNCjIwMDEvOS8xOCAgDQo=

[linuxsh-dev] stable SH4 environment

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

While it takes weeks to test tool-chain, I've confirmed that
it is stable enough to boot-strap Debain GNU/Linux for SuperH.
I've put the diff under ftp://ftp.m17n.org/pub/linux-sh/testing/

	gcc-sh-linux_3.0.1-8.diff.gz
	binutils-sh-linux_2.11.2-1.diff.gz

It's basically for Debian (includes Debian specific files), but non-Debian
specific parts are applicable.  Please try.

I've run the testsuite of GCC native on SH-4.  It's not bad.

NOTE: For GCC, "make bootstrap" does not go well, it's wierd that GCC
compiled for -O0 doesn't work but -O2 works well.  (The result of test
is based on GCC with -O2 (natively compiled))

		=== gcc Summary ===

# of expected passes		15152
# of unexpected failures	29
# of expected failures		75
# of unsupported tests		52

--------------------------
FAIL: gcc.c-torture/compile/20001226-1.c,  -O1  
FAIL: gcc.c-torture/compile/20001226-1.c,  -O2  
FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -fomit-frame-pointer  
FAIL: gcc.c-torture/compile/20001226-1.c,  -O3 -g  
FAIL: gcc.c-torture/compile/20001226-1.c,  -Os  
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-1.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-2.c execution,  -Os 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O0 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/fp-cmp-3.c execution,  -Os 

--------------------------
-- 

[linuxsh-dev] [PATCH] Makefile Cross Compile Sanity Check

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

Paul Mundt wrote:
 > The attached patch will only have $(tool-prefix) assigned in the event that
 > CROSS_COMPILE hasn't already been set in the toplevel Makefile.

Thanks, it's good.  Further, how about removing the whole the clause?
I mean, never use tool_prefix.

I think that the Makefile was just taken from MIPS implementation
where tool-prefix depends on target.

The makefile desigen would be to specify CROSS_COMPILE, while we have
had to specify tool_prefix (IIRC, older make (3.77?) complain '-').
In case of MIPS, tool-prefix has good meaning, perhaps, it may be
convinient to override.  For SuperH, just follow standard way, 
that is, specify CROSS_COMPILE is good.
--