linuxsh-dev

Re: [linuxsh-dev] How to link sh-IPL+g

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

Fabio

The only thing sh-stub needs to know is where RAM and ROM are.
Your board uses the standard Hitachi layout, so you can use the same
file as the SH4 SolutionEngine (sesh3.mem).

You will probably need to modify the init-xxx.S file you use though,
to set up the right memory timings for your board.

Stuart

On Tue, 19 Mar 2002 09:18:03 +0100
fg...@ti... wrote:

> I have a sh-3 7709a based board with the following memory map:
> 00000000h	Area0	Flash ROM
> 04000000h	Area1	SH7709A Internal Registers
> 08000000h	Area2	SH Bus
> 0C000000h	Area3	SDRAM
> 10000000h	Area4	Companion Chip
> 14000000h	Area5	SED 1355
> 18000000h	Area6	PCMCIA/ISA
> 1C000000h	Area7	SH7709A Internal Registers
> 
> 
> How I have to set .mem file to execute the sh-stub form Area 0.
> 
> 
> Thanks a lot.
> 
> Fabio Giovagnini
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev


-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

[linuxsh-dev] How to link sh-IPL+g

[Fabio G. <fg...@ti...>]

I have a sh-3 7709a based board with the following memory map:
00000000h	Area0	Flash ROM
04000000h	Area1	SH7709A Internal Registers
08000000h	Area2	SH Bus
0C000000h	Area3	SDRAM
10000000h	Area4	Companion Chip
14000000h	Area5	SED 1355
18000000h	Area6	PCMCIA/ISA
1C000000h	Area7	SH7709A Internal Registers


How I have to set .mem file to execute the sh-stub form Area 0.


Thanks a lot.

Fabio Giovagnini

[linuxsh-dev] 2.5.4 follow-up

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

I forgot to send this here and commit to the repository.  Here's
follow up to 2.5.4.  Also includes move of joystick driver to
drivers/input/.

2002-03-09  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/mm/cache-sh4.c (flush_cache_range): New auto variable mm.

	* arch/sh/kernel/process.c (get_wchan): Follow the API change of
	thread_saved_pc.

	* include/asm-sh/thread_info.h (cpu): Added the member, not
	meaningful though (SuperH doesn't support SMP).

	* include/asm-sh/semaphore.h: Include <linux/wait.h>.

	* include/asm-sh/processor.h (thread_saved_pc): Make it a macro,
	so that we don't need the implementation of struct task.
	Fixed, thread is not a pointer.

	* arch/sh/config.in: joystick driver is now under drivers/input.

	* arch/sh/kernel/entry.S (flags, work, syscall_trace): Removed.
	(k_current): Removed.
	(work_pending): Use _TIF_NEED_RESCHED.
	(work_resched): Use GET_THREAD_INFO and _TIF_WORK_MASK.
	(work_notifysig): Use _TIF_SIGPENDING.
	(resume_userspace): Use GET_THREAD_INFO and _TIF_WORK_MASK.
	(system_call): Use GET_THREAD_INFO and _TIF_SYSCALL_TRACE.
	(system_exit): Use GET_THREAD_INFO and _TIF_ALLWORK_MASK.
	(system_trace_entry): Use _TIF_SYSCALL_TRACE.

	* include/asm-sh/thread_info.h (_TIF_WORK_MASK, _TIF_ALLWORK_MASK): 
	Change the value to 8-bit.

Index: arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/config.in,v
retrieving revision 1.4
diff -u -3 -p -r1.4 config.in
--- arch/sh/config.in	25 Jan 2002 02:07:59 -0000	1.4
+++ arch/sh/config.in	19 Mar 2002 07:20:55 -0000
@@ -259,7 +259,7 @@ fi
 endmenu
 
 #
-# input before char - char/joystick depends on it. As does USB.
+# input - input/joystick depends on it. As does USB.
 #
 source drivers/input/Config.in
 
@@ -308,7 +308,7 @@ if [ "$CONFIG_SH_DREAMCAST" = "y" -a "$C
    endmenu
 fi
 
-source drivers/char/joystick/Config.in
+source drivers/input/joystick/Config.in
 
 if [ "$CONFIG_PARPORT" != "n" ]; then
    dep_tristate 'Parallel printer support' CONFIG_PRINTER $CONFIG_PARPORT
Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/entry.S,v
retrieving revision 1.4
diff -u -3 -p -r1.4 entry.S
--- arch/sh/kernel/entry.S	1 Mar 2002 01:55:10 -0000	1.4
+++ arch/sh/kernel/entry.S	19 Mar 2002 07:20:55 -0000
@@ -13,6 +13,7 @@
 #include <linux/sys.h>
 #include <linux/linkage.h>
 #include <linux/config.h>
+#include <asm/thread_info.h>
 
 
 ! NOTE:
@@ -51,13 +52,6 @@
  *
  */
 
-/*
- * These are offsets into the task-struct.
- */
-flags		=  4
-work		=  8
-syscall_trace	= work+1
-
 ENOSYS = 38
 EINVAL = 22
 
@@ -97,11 +91,10 @@ SYSCALL_NR =  (16*4+6*4)
 #define k3	r3
 #define k4	r4
 
-#define current		r7	/* r7_bank1 */
+#define k_ex_code	r2_bank	/* r2_bank1 */
 #define g_imask		r6	/* r6_bank1 */
-#define k_current	r7_bank	/* r7_bank1 */
 #define k_g_imask	r6_bank	/* r6_bank1 */
-#define k_ex_code	r2_bank	/* r2_bank1 */
+#define current		r7	/* r7_bank1 */
 
 /*
  * Kernel mode register usage:
@@ -112,7 +105,7 @@ SYSCALL_NR =  (16*4+6*4)
  *	k4	scratch
  *	k5	reserved
  *	k6	Global Interrupt Mask (0--15 << 4)
- *	k7	CURRENT (pointer to current task)
+ *	k7	CURRENT_THREAD_INFO (pointer to current thread info)
  */
 
 !
@@ -291,15 +284,8 @@ ENTRY(ret_from_fork)
 
 	.align	2
 work_pending:
-	! r1: current->work
-#ifdef	__LITTLE_ENDIAN__
-#else
-	swap.w	r1, r0
-	swap.b	r0, r0
-#endif
-	and	#0xff,r0
-	! r0: current->work.need_resched
-	tst	r0, r0
+	! r0: current_thread_info->flags
+	tst	#_TIF_NEED_RESCHED, r0
 	bt	work_notifysig
 
 	.align	2
@@ -312,30 +298,22 @@ work_resched:
 	or	#0xf0, r0
 	ldc	r0, sr
 	!
-	stc	k_current, r1
-	mov.l	@(work,r1), r1
-	mov.l	2f, r0
-	and	r1, r0
-	tst	r0, r0
+	GET_THREAD_INFO(r1)
+	add	#TI_FLAGS, r1
+	mov.l	@r1, r0		! current_thread_info->flags
+	tst	#_TIF_WORK_MASK, r0
 	bt	restore_all
 	bra	work_pending
 	 nop
 
 	.align	2
 work_notifysig:
-	! r1: current->work
-#ifdef	__LITTLE_ENDIAN__
-	swap.w	r1, r0
-#else
-	swap.b	r0, r0
-#endif
-	and	#0xff,r0
-	! r0: current->work.sigpending
-	tst	r0, r0
+	! r0: current_thread_info->flags
+	tst	#_TIF_SIGPENDING, r0
 	bt	restore_all
 	mov	r15, r4
 	mov	#0, r5
-	mov.l	3f, r1
+	mov.l	2f, r1
 	mova	restore_all, r0
 	jmp	@r1
 	 lds	r0, pr
@@ -346,24 +324,17 @@ ENTRY(resume_userspace)
 	or	#0xf0, r0
 	ldc	r0, sr
 	!
-	stc	k_current, r1
-	mov.l	@(work,r1), r1		! current->work
-	mov.l	2f, r0
-	and	r1, r0
-	tst	r0, r0
+	GET_THREAD_INFO(r1)
+	add	#TI_FLAGS, r1
+	mov.l	@r1, r0		! current_thread_info->flags
+	tst	#_TIF_WORK_MASK, r0
 	bf	work_pending
 	bra	restore_all
 	 nop
 
 	.align	2
 1:	.long	SYMBOL_NAME(schedule)
-2:	! ignore syscall trace counter
-#ifdef	__LITTLE_ENDIAN__
-	.long	0xffff00ff
-#else
-	.long	0xff00ffff
-#endif
-3:
+2:
 	.long	SYMBOL_NAME(do_signal)
 
 /*
@@ -420,10 +391,11 @@ system_call:
 	bt	syscall_badsys
 	!
 	!   	    	    Good syscall number
-	stc	k_current, r11
-	add	#syscall_trace, r11
-	mov.b	@r11, r10
-	tst	r10, r10
+	GET_THREAD_INFO(r11)
+	add	#TI_FLAGS, r11
+	mov.l	@r11, r10
+	mov	#_TIF_SYSCALL_TRACE, r11
+	tst	r11, r10
 	bf	syscall_trace_entry
 	!
 syscall_call:
@@ -440,9 +412,10 @@ syscall_exit:
 	or	#0xf0, r0
 	ldc	r0, sr
 	!
-	stc	k_current, r1
-	mov.l	@(work,r1), r1		! current->work
-	tst	r1, r1
+	GET_THREAD_INFO(r1)
+	add	#TI_FLAGS, r1
+	mov.l	@r1, r0		! current_thread_info->flags
+	tst	#_TIF_ALLWORK_MASK, r0
 	bf	syscall_exit_work
 restore_all:
 	mov.l	@r15+, r0
@@ -536,15 +509,8 @@ syscall_trace_entry:
 
 	.align	2
 syscall_exit_work:
-	! r1: current->work
-#ifdef	__LITTLE_ENDIAN__
-	swap.b	r1, r0
-#else
-	swap.w	r1, r0
-#endif
-	and	#0xff,r0
-	! r0: current->work.syscall_trace
-	tst	r0, r0
+	! r0: current_thread_info->flags
+	tst	#_TIF_SYSCALL_TRACE, r0
 	bt	work_pending
 	STI()
 	! XXX setup arguments...
Index: arch/sh/kernel/process.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/process.c,v
retrieving revision 1.5
diff -u -3 -p -r1.5 process.c
--- arch/sh/kernel/process.c	6 Mar 2002 23:04:52 -0000	1.5
+++ arch/sh/kernel/process.c	19 Mar 2002 07:20:55 -0000
@@ -347,7 +347,7 @@ unsigned long get_wchan(struct task_stru
 	/*
 	 * The same comment as on the Alpha applies here, too ...
 	 */
-	pc = thread_saved_pc(&p->thread);
+	pc = thread_saved_pc(p);
 	if (pc >= (unsigned long) interruptible_sleep_on && pc < (unsigned long) add_timer) {
 		schedule_frame = ((unsigned long *)(long)p->thread.sp)[1];
 		return (unsigned long)((unsigned long *)schedule_frame)[1];
Index: arch/sh/mm/cache-sh4.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.3
diff -u -3 -p -r1.3 cache-sh4.c
--- arch/sh/mm/cache-sh4.c	1 Mar 2002 07:47:11 -0000	1.3
+++ arch/sh/mm/cache-sh4.c	19 Mar 2002 07:20:55 -0000
@@ -322,6 +322,7 @@ void flush_cache_range(struct vm_area_st
 		       unsigned long end)
 {
 	unsigned long flags;
+	struct mm_struct *mm = vma->vm_mm;
 
 	if (mm->context == 0)
 		return;
Index: include/asm-sh/processor.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/processor.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 processor.h
--- include/asm-sh/processor.h	6 Mar 2002 23:04:52 -0000	1.3
+++ include/asm-sh/processor.h	19 Mar 2002 07:20:55 -0000
@@ -204,10 +204,7 @@ extern void save_fpu(struct task_struct 
 /*
  * Return saved PC of a blocked thread.
  */
-static __inline__ unsigned long thread_saved_pc(struct task_struct *tsk)
-{
-	return tsk->thread->pc;
-}
+#define thread_saved_pc(tsk)	(tsk->thread.pc)
 
 extern unsigned long get_wchan(struct task_struct *p);
 
Index: include/asm-sh/semaphore.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/semaphore.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -r1.1.1.1 semaphore.h
--- include/asm-sh/semaphore.h	15 Oct 2001 20:45:11 -0000	1.1.1.1
+++ include/asm-sh/semaphore.h	19 Mar 2002 07:20:55 -0000
@@ -15,6 +15,7 @@
 
 #include <linux/spinlock.h>
 #include <linux/rwsem.h>
+#include <linux/wait.h>
 
 #include <asm/system.h>
 #include <asm/atomic.h>
Index: include/asm-sh/thread_info.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/thread_info.h,v
retrieving revision 1.1
diff -u -3 -p -r1.1 thread_info.h
--- include/asm-sh/thread_info.h	6 Mar 2002 23:04:52 -0000	1.1
+++ include/asm-sh/thread_info.h	19 Mar 2002 07:20:55 -0000
@@ -29,6 +29,7 @@ struct thread_info {
 	__u32			flags;		/* low level flags */
 	__s32			preempt_count; /* 0 => preemptable, <0 => BUG */
 
+	__u32			cpu;
 	__u8			supervisor_stack[0];
 };
 
@@ -102,8 +103,8 @@ static inline struct thread_info *curren
 #define _TIF_POLLING_NRFLAG	(1<<TIF_POLLING_NRFLAG)
 #define _TIF_USERSPACE		(1<<TIF_USERSPACE)
 
-#define _TIF_WORK_MASK		0x0000FFFE	/* work to do on interrupt/exception return */
-#define _TIF_ALLWORK_MASK	0x0000FFFF	/* work to do on any return to u-space */
+#define _TIF_WORK_MASK		0x000000FE	/* work to do on interrupt/exception return */
+#define _TIF_ALLWORK_MASK	0x000000FF	/* work to do on any return to u-space */
 
 #endif /* __KERNEL__ */
 

Re: [linuxsh-dev] TMU1 and KGDB patches

[Paul M. <le...@Ch...>]

On Mon, Mar 18, 2002 at 10:52:01AM -0800, Jeremy Siegel wrote:
> I haven't heard any objections to the TMU1 and KGDB patches I sent out a
> couple weeks ago, so I'll commit them in the next day or two.  [Masahiro
> Abe was the only respondent regarding TMU1, and after some discussion he
> thought the change was fine.]
>=20
I've applied both to the restructure branch already, they went in relatively
effortlessly. You shouldn't have any problems pushing them into HEAD.

This does mean that extra care will have to be taken with sync ups with Lin=
us
though, since Linus doesn't like kernel debuggers.

Regards,

--=20
Paul Mundt <le...@ch...>

[linuxsh-dev] TMU1 and KGDB patches

[Jeremy S. <js...@mv...>]

Hi folks,

I haven't heard any objections to the TMU1 and KGDB patches I sent out a
couple weeks ago, so I'll commit them in the next day or two.  [Masahiro
Abe was the only respondent regarding TMU1, and after some discussion he
thought the change was fine.]

--Jeremy Siegel

[linuxsh-dev] NFS issues

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

We're using NFS-root environment and have been getting kernel message
of:
	nfs_refresh_inode: inode XXXXXXX mode changed, OOOO to OOOO

(We use user space NFS v2 server on top of ext3 file system.)

I'm not sure if this is SuperH specific.  I'm now using following
patch with no problem.

Anyone has this problem?

--- linux-2.4.18/fs/nfs/inode.c~	Wed Mar 13 17:56:48 2002
+++ linux-2.4.18.superh/fs/nfs/inode.c	Mon Mar 18 13:27:39 2002
@@ -680,8 +680,10 @@ nfs_find_actor(struct inode *inode, unsi
 	if (is_bad_inode(inode))
 		return 0;
 	/* Force an attribute cache update if inode->i_count == 0 */
-	if (!atomic_read(&inode->i_count))
+	if (!atomic_read(&inode->i_count)) {
 		NFS_CACHEINV(inode);
+		inode->i_mode = 0;
+	}
 	return 1;
 }
 
-- 

Re: [linuxsh-dev] SH-5 integration issues

[Paul M. <le...@Ch...>]

On Sat, Mar 16, 2002 at 04:32:57AM +0000, Stuart Menefy wrote:
> I still can't make up my mind whether we should try and go for a full
> 64 bit port or not, or if it even makes sense with the current
> hardware. However whatever we do about merging or not and naming, we
> should try and define interfaces now which would allow 64 bit support
> in the future - system calls being the most obvious one, but I'm sure
> there are others. Whether we start work on making the current tree
> properly 64 bit now, or wait until a true 64 bit device appears really
> depends on people's time and inclination.
>=20
This is somewhat of a double-edged sword. Really, the SH5 code could be
treated as both .. straight shmedia, and shmedia64. The problem with that
though is that there's endless amounts of duplication between the two, so it
seems to really be more of an "all or nothing" situation. However, if there=
's
enough interest in treating it as a real 64-bit port, that's really the only
sane way to deal with it.

> Having proposed sh5 in the first place, I've now changed my mind! I
> think Dave's suggestion of shmedia (or something similar) might
> actually be a better choice.
>=20
> Given that what we are talking about is actually the architecture of
> the SH5 actually being different from the SH4 (instruction set being
> the obvious example), this seems like a good way to distinguish
> them. And it has the big advantage that when SH6/7/8 or whatever comes
> along (and whether we go for a true 64 it port now, in the future or
> never), we're not left with a misleading name, which both sh5 and sh64
> could be.
>=20
shmedia would indeed not be misleading, but what about when people start
wanting a "real" 64-bit port for SH5/6? or what's if SH7/8 suddenly jump to
64-bit addressing? I suppose in that sense, shmedia64 makes sense, though t=
hen
there's quirkiness to deal with in addressing changes. Treating SH5/6 as
shmedia64 shouldn't be too big of a deal, but as soon as something that uses
true 64-bit addressing comes along, it gets a little bit messy.

> I'm speculating here as well, I don't know what SuperH's plans are for
> anything beyond SH5, and I doubt if they do either. It will all depend
> on what the market demands. So I wouldn't hold my breath waiting for
> an answer to any of these quiestions.
>=20
> However, I do think SHmedia is the future. Its 64 bit, it should be
> quite a bit faster, and it was designed with an eye to future CPU
> directions (superscaler, super-pipelined, high ratio of CPU to memory
> speeds etc). It also has room for expansion (lots of unused
> instruction opcodes) unlike SH4/SHcompact.
>=20
Judging from what SuperH has been saying about SH6 so far, it'll be an
extension to SH5 .. an extension in the sense that it'll be super-scalar as
well as super-pipelined. It'll still retain SHmedia, as well as 32-bit
addressing. (That's all subject to change naturally, though.)

> I think the question becomes whether is it worth SuperH maintaining
> support for SHcompact in future SHmedia based devices.
>=20
> SHcompact has two attributes:
>  - it has a certain level of binary compatibility with SH4
>  - it is compact (!)
>=20
> I suspect compatibility with SH4 was thought to be important in the
> WinCE/HPC market, where the ability to continue to run old binary
> applications might be useful. Unfortunately that market appears to have
> been lost to ARM, so I think that requirement has gone away.
> I know implementing a single CPU which could execute both instruction
> sets efficiently caused lots of problems to the designers, so as clock
> rates go up they will be looking for areas to simplify, and SHcompact
> would be a candidate.
>=20
I suppose this really depends what kind of value people put on backwards
compatability, other then just the buzzword-compliance issue. For the market
that SH5 seems to be after, I don't see too many people caring about backwa=
rds
compatability, especially at the ABI level.

For things like WinCE, that's certainly something that could be potentially
beneficial .. but then again, the majority of the SH-based handhelds that w=
ere
floating around were still using a 7709 of some sort. I can count the number
of SH4 based PPC/HPC's on one hand, and this does certainly seem to be a de=
ad
market now as well (at least for non-ARM, even MIPS is experiencing hurdles,
people are resorting to forking the WinCE code base). PocketPC 2002 has pre=
tty
much obliterated non-ARM from the market anyways.

I don't see SHcompact living on past SH6. Especially when comparing SHcompa=
ct
instructions to some of the SH5 SIMD instructions, the future for SHcompact
looks rather bleak. Instruction size is a bit of a nuisance .. SHmedia will
force SH into the same sizes that people like MIPS play in, which is
unfortunately rather largeish. But at the same time, with SHcompact really
only being useful for non-critical performance applications where binary si=
ze
is more of a concern than speed, you have to kind of stop and wonder what
people are using SH5 for in the first place.

> That is not to say that the current SH4 will not be enhanced. I would
> expect SuperH to continue to enhance the SH4, but if they do that I
> would expect the device to be supported by the current Linux sh
> architecture part of the tree. Although what it will be called in
> anybody's guess, maybe they will have to resort to fractional numbers:
> SH4.1 perhaps!
>=20
The current SH4 is being enhanced. Things like the 7751R for instance. Larg=
er
caches, two-way set associative caches, etc, etc.

> I think the 32/64 bit argument is a bit of blind alley at the
> moment. The issue from my point of view is that the SH3/4 and SH5
> architectures are different (instruction sets, interrupt controllers,
> MMU, caches, PCI, etc.) so there would be very little common code. In
> fact I suspect they would share only slightly more code than sh does
> with i386 (which is actually quite a lot!).
>=20
Interrupt controllers, MMU handling, caches, PCI differences, etc, etc. are
_all_ common differences between any processor. This in itself does not
warrant the creation of a new architecture under linux. MIPS deals with this
all the time.

Things like the instruction set differences start becoming more of an issue
though.. supporting multiple entry.S/head.S's and ifdef'ing inbetween them =
is
ugly, at best.

> As the SH5 architecture is capable of supporting 64 bit operation,
> differences between a 32 or 64 bit implementation should be very
> small, and hopefully constrained to some #ifdefs in header
> files. The one exception to this might be how to handle the PCI
> interface in a 64 bit world, but at least that is constrained to no
> more than a few files.
>=20
Agreed, there shouldn't be too many differences between the two. But as soon
as you start running into things that do "real" 64-bit addressing, things
might start to get a little uglier..=20

> The presence of SHmedia to aid backward compatibility complicates the
> issue, but the approach we have taken with the port is to not use it
> in the kernel. This was done mainly for performance reasons, but also
> to leave to door open for 64 bit support, and some nagging doubts
> about its future.
>=20
Er, I presume you mean SHcompact here?

> So my vote would be to put treat the SH5 as a new architecture, called:
>   First choice:  shmedia
>   Second choice: sh5
>   Third choice:  sh64
>=20
Since SH6 will most likely be folded relatively easily into the SH5 code ba=
se,
I don't see the second choice here as being something to consider. shmedia
sounds fine, but I'm still leaning more towards sh64 simply for cleanliness=
 ..
the problem comes in when you start having true 64-bit platforms (potential=
ly
SH7/8) vs faked 64-bit platforms with 32-bit addressing (SH5/6).

Bearing this in mind, my vote looks something like:

  First choice:  sh64
  Second choice: shmedia

And I'm leaving out the third choice, as I don't really see one that's viab=
le.

Regards,

--=20
Paul Mundt <le...@ch...>

Re: [linuxsh-dev] SH-5 integration issues

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

On Fri, 15 Mar 2002 18:40:28 +0000
dav...@st... wrote:

> mr...@0x... wrote:
> > 
> > Paul and I have been trying to determine the best fit for the SH-5 port for
> > 2.5.  The problem lies in the SH-5's (and SH-6's) addressing - it's 32-bit
> > versus 64-bit, so the standard kernel convention for a 64-bit port doesn't
> > necessarily qualify it as "sh64" (but hey, we're kernel hackers, we can
> > bend the rules :P).
> 
> Well, I don't see any problem calling it a 64 bit. For me, the
> fundamental criteria
> for calling it a 64 bit port is that a pointer is 64 bits. This is
> supported by the 
> gcc toolchain (I've never tried it though), and all the internal
> registers are quite 
> happy with 64 bits. Yes, it is true that at the moment on the SH5 you
> can't address more 
> than 32 bits of physical, but I would view this as an implementation
> detail, not an architecture 
> restriction.  I agree that is a pain that the 64bitness is implemented
> by sign extension
> rather than real bits, but it is possible to build a kernel that would
> work with this way 
> of doing things and "real" 64 bits without too much pain I think.

I still can't make up my mind whether we should try and go for a full
64 bit port or not, or if it even makes sense with the current
hardware. However whatever we do about merging or not and naming, we
should try and define interfaces now which would allow 64 bit support
in the future - system calls being the most obvious one, but I'm sure
there are others. Whether we start work on making the current tree
properly 64 bit now, or wait until a true 64 bit device appears really
depends on people's time and inclination.

> Anyway, the current port isn't 64 bit, which is why it is an sh5
> directory rather than
> sh64. It should really be called shmedia in retrospect I suppose.

Having proposed sh5 in the first place, I've now changed my mind! I
think Dave's suggestion of shmedia (or something similar) might
actually be a better choice.

Given that what we are talking about is actually the architecture of
the SH5 actually being different from the SH4 (instruction set being
the obvious example), this seems like a good way to distinguish
them. And it has the big advantage that when SH6/7/8 or whatever comes
along (and whether we go for a true 64 it port now, in the future or
never), we're not left with a misleading name, which both sh5 and sh64
could be.

> > Moving the SH-5 port in with the sh/ arch is a challenge
> 
> Absolutely. What I do not understand is what benefit you see from doing
> it this way. 
> As far as I can see it will simply make a mess of the current SH
> support, as it is 
> a different machine from an OS point of view.  Every arch specific file
> will be duplicated, 
> and will create an unholy mess for no benefit. Please explain what you
> see as the benefits.
> 
> 
> > is trying to plan for structuring future SH processors.  Will the SH-7 and
> > SH-8 retain the SHmedia instructions and 32-bit addressing?  Or will
> > Hitachi have a change of mind and switch to 64-bit addressing if the market
> > calls for it?
> > 
> 
> Rememeber that the architecture of future SH processors is controlled by
> SuperH Inc,
> not Hitachi. However, Hitachi and ourselves at ST can be safely
> described as major customers 
> of SuperH. I also think you have answered your own question, if somebody
> wants a real 64 machine
> I'm sure SuperH will be more than happy to oblige, given that the
> architecture is already 64 bit 
> so a 64 bit everywhere machine would be very easy for them to build. I
> do not think they will
> categorically state that they will never build a full 64 bit machine.
> Anybody at superh care to 
> comment?
> 
> As to SHmedia, I think that it is here to stay. It is the main
> instructions set of 
> the machine. A more pertinant question would be how long  SHcompact
> stays around for.
> Backward compatibilty costs both in terms of silicon area and
> verification, so it is 
> not beyond the realms of possibility that SuperH would produce a future
> processor that 
> is SHmedia only.  I can't speak for SuperH here, but it must be regarded
> as a possibility.
> Again I suspect that you will not get a statement saying SuperH will
> always support
> SHcompact in hardware indefinately for all future machines. Comments
> from SuperH are invited.

I'm speculating here as well, I don't know what SuperH's plans are for
anything beyond SH5, and I doubt if they do either. It will all depend
on what the market demands. So I wouldn't hold my breath waiting for
an answer to any of these quiestions.

However, I do think SHmedia is the future. Its 64 bit, it should be
quite a bit faster, and it was designed with an eye to future CPU
directions (superscaler, super-pipelined, high ratio of CPU to memory
speeds etc). It also has room for expansion (lots of unused
instruction opcodes) unlike SH4/SHcompact.

I think the question becomes whether is it worth SuperH maintaining
support for SHcompact in future SHmedia based devices.

SHcompact has two attributes:
 - it has a certain level of binary compatibility with SH4
 - it is compact (!)

I suspect compatibility with SH4 was thought to be important in the
WinCE/HPC market, where the ability to continue to run old binary
applications might be useful. Unfortunately that market appears to have
been lost to ARM, so I think that requirement has gone away.
I know implementing a single CPU which could execute both instruction
sets efficiently caused lots of problems to the designers, so as clock
rates go up they will be looking for areas to simplify, and SHcompact
would be a candidate.

The compact nature of SHmedia is still of interest, in areas where code
density is more important than performance. However I think it is
unfortunate that SuperH decided to get compact encoding in this way,
as it is partly for this reason that the SH5 is still limited to 32 bits
in some areas. Remember you can inter-call SHmedia and SHcompact functions,
so imagine a function call from code written in SHmedia to a function in
SHcompact code, which takes a pointer as a parameter. That parameter is
passed in a 64 bit register, but the called code can only see 32 bits of
it. While you have to support this scenario, there is probably no point
in going to more than 32 bit addressing.

So my guess would be that in future SHx variants, SHcompact has to be
under threat. It will start to get in the way either when they push up
the clock rate, or try to go true 64 bit. So at one extreme it could
be dropped, or it may start to become slower relative to SHmedia
(because it is being emulated at some level), or at the very least,
mixed mode programs will be restricted to 32 bit virtual addresses
only, and if you want to use 64 bit addressing the code must be pure
SHmedia.

That is not to say that the current SH4 will not be enhanced. I would
expect SuperH to continue to enhance the SH4, but if they do that I
would expect the device to be supported by the current Linux sh
architecture part of the tree. Although what it will be called in
anybody's guess, maybe they will have to resort to fractional numbers:
SH4.1 perhaps!

However, I reiterate, this is personal opinion only, based on no facts
whatsoever.

> > If future SH processors are "true" 64-bit machines (well addressing at
> > least), then it makes sense for the SH-5 and SH-6 to live with the SH-3 and
> > SH-4 code, but if the SH-7 and SH-8 retain current SHmedia and 32-bit
> > addressing (e.g. they won't differ "externally" from the SH-5 or SH-6), then
> > it makes sense for all SHmedia capable processors to live in "sh64".  This is
> > why we need a bit of clarification (if at all possible) of the plans to stick
> > with 32-bit addressing, so it'll potentially save us some work down the road.

I think the 32/64 bit argument is a bit of blind alley at the
moment. The issue from my point of view is that the SH3/4 and SH5
architectures are different (instruction sets, interrupt controllers,
MMU, caches, PCI, etc.) so there would be very little common code. In
fact I suspect they would share only slightly more code than sh does
with i386 (which is actually quite a lot!).

As the SH5 architecture is capable of supporting 64 bit operation,
differences between a 32 or 64 bit implementation should be very
small, and hopefully constrained to some #ifdefs in header
files. The one exception to this might be how to handle the PCI
interface in a 64 bit world, but at least that is constrained to no
more than a few files.

The presence of SHmedia to aid backward compatibility complicates the
issue, but the approach we have taken with the port is to not use it
in the kernel. This was done mainly for performance reasons, but also
to leave to door open for 64 bit support, and some nagging doubts
about its future.

So my vote would be to put treat the SH5 as a new architecture, called:
  First choice:  shmedia
  Second choice: sh5
  Third choice:  sh64

Stuart

Fwd: Re: [linuxsh-dev] SH-5 integration issues

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

I screwed up and only sent this to David.  My mistake.

M. R.

----- Forwarded message from "M. R. Brown" <mr...@0x...> -----

From: "M. R. Brown" <mr...@0x...>
Subject: Re: [linuxsh-dev] SH-5 integration issues
Date: Fri, 15 Mar 2002 13:09:07 -0600
To: David McKay <dav...@st...>

* David McKay <dav...@st...> on Fri, Mar 15, 2002:

>=20
>=20
> Anyway, the current port isn't 64 bit, which is why it is an sh5
> directory rather than
> sh64. It should really be called shmedia in retrospect I suppose.
>=20

Indeed.

> Absolutely. What I do not understand is what benefit you see from doing
> it this way.=20
> As far as I can see it will simply make a mess of the current SH
> support, as it is=20
> a different machine from an OS point of view.  Every arch specific file
> will be duplicated,=20
> and will create an unholy mess for no benefit. Please explain what you
> see as the benefits.
>=20

We didn't see any benefits, but we don't want to necessarily tramp over the
current arch conventions that govern the kernel right now.  Even though
it's a different machine it's still a "sh", so we were looking for clues as
to where to best place it in the "sh" echelon.

>=20
> Again, I don't understand why you want to include sh5 code in
> with the SH3/4 stuff. It will be a maintenance nightmare. If we think a
> 64 bit port
> is a good idea, then lets create an sh64 directory and be done with it.
> Otherwise lets=20
> stick to sh5 as a new 32 architecture (since it is effectively a new
> machine).=20
>=20

Hmm, I dunno.  If it's not a true 64-bit architecture (and convention
dictates it isn't), sh64 would be a misnomer, unless we can absolutely
confirm from SuperH a move to 64-bit addressing.  I guess at this
point it does make sense to look at a name like shmedia (I'm not opposed to
that), so we can move on to bigger and better things.

Ok, so we were definitely going down the wrong path there, thanks.

>=20
> And also, I confess I am confused to exactly who you are going to make
> this formal proposal to. Could you explain this further?
>=20

Heh, to the mailing list, of course.  Since Paul and I have primarily been
handling the 2.5 restructure work, we want to make sure we get the "nod"
from everyone else in the community (including SuperH and friends), before
we continue.  Nothing more complex than that :).

Thanks,

M. R.



----- End forwarded message -----

Re: [linuxsh-dev] SH-5 integration issues

[David W. <dw...@in...>]

js...@mv... said:
>  And if there's already a sparc and sparc64, and mips and mips64, why
> not an shnew and shnew64?  (Is it because the other have major system
> architecture changes between 32-bit and 64-bit implementations, while
> the SH5 has already incorporated all such major changes?)

Due to lots of duplicated code, there's work under way to merge mips and 
mips64. 

--
dwmw2

Re: [linuxsh-dev] SH-5 integration issues

[Jeremy S. <js...@mv...>]

I'm far from knowledgeable about the SH5, but it sure sounds to me like it should
be a different arch... not least because the people who've been working most
closely with it (doing the port) seem to feel that way.  Maybe call it "shm" or
"shx" if the longer "shmedia" that was suggested is unacceptable for some reason.

And if there's already a sparc and sparc64, and mips and mips64, why not an shnew
and shnew64?  (Is it because the other have major system architecture changes
between 32-bit and 64-bit implementations, while the SH5 has already incorporated
all such major changes?)

--Jeremy Siegel


David McKay wrote:

> mr...@0x... wrote:
> >
> > Paul and I have been trying to determine the best fit for the SH-5 port for
> > 2.5.  The problem lies in the SH-5's (and SH-6's) addressing - it's 32-bit
> > versus 64-bit, so the standard kernel convention for a 64-bit port doesn't
> > necessarily qualify it as "sh64" (but hey, we're kernel hackers, we can
> > bend the rules :P).
>
> Well, I don't see any problem calling it a 64 bit. For me, the
> fundamental criteria
> for calling it a 64 bit port is that a pointer is 64 bits. This is
> supported by the
> gcc toolchain (I've never tried it though), and all the internal
> registers are quite
> happy with 64 bits. Yes, it is true that at the moment on the SH5 you
> can't address more
> than 32 bits of physical, but I would view this as an implementation
> detail, not an architecture
> restriction.  I agree that is a pain that the 64bitness is implemented
> by sign extension
> rather than real bits, but it is possible to build a kernel that would
> work with this way
> of doing things and "real" 64 bits without too much pain I think.
>
> Anyway, the current port isn't 64 bit, which is why it is an sh5
> directory rather than
> sh64. It should really be called shmedia in retrospect I suppose.
>
> > Moving the SH-5 port in with the sh/ arch is a challenge
>
> Absolutely. What I do not understand is what benefit you see from doing
> it this way.
> As far as I can see it will simply make a mess of the current SH
> support, as it is
> a different machine from an OS point of view.  Every arch specific file
> will be duplicated,
> and will create an unholy mess for no benefit. Please explain what you
> see as the benefits.
>
> > is trying to plan for structuring future SH processors.  Will the SH-7 and
> > SH-8 retain the SHmedia instructions and 32-bit addressing?  Or will
> > Hitachi have a change of mind and switch to 64-bit addressing if the market
> > calls for it?
> >
>
> Rememeber that the architecture of future SH processors is controlled by
> SuperH Inc,
> not Hitachi. However, Hitachi and ourselves at ST can be safely
> described as major customers
> of SuperH. I also think you have answered your own question, if somebody
> wants a real 64 machine
> I'm sure SuperH will be more than happy to oblige, given that the
> architecture is already 64 bit
> so a 64 bit everywhere machine would be very easy for them to build. I
> do not think they will
> categorically state that they will never build a full 64 bit machine.
> Anybody at superh care to
> comment?
>
> As to SHmedia, I think that it is here to stay. It is the main
> instructions set of
> the machine. A more pertinant question would be how long  SHcompact
> stays around for.
> Backward compatibilty costs both in terms of silicon area and
> verification, so it is
> not beyond the realms of possibility that SuperH would produce a future
> processor that
> is SHmedia only.  I can't speak for SuperH here, but it must be regarded
> as a possibility.
> Again I suspect that you will not get a statement saying SuperH will
> always support
> SHcompact in hardware indefinately for all future machines. Comments
> from SuperH are invited.
>
> > If future SH processors are "true" 64-bit machines (well addressing at
> > least), then it makes sense for the SH-5 and SH-6 to live with the SH-3 and
> > SH-4 code, but if the SH-7 and SH-8 retain current SHmedia and 32-bit
> > addressing (e.g. they won't differ "externally" from the SH-5 or SH-6), then
> > it makes sense for all SHmedia capable processors to live in "sh64".  This is
> > why we need a bit of clarification (if at all possible) of the plans to stick
> > with 32-bit addressing, so it'll potentially save us some work down the road.
> >
>
> Again, I don't understand why you want to include sh5 code in
> with the SH3/4 stuff. It will be a maintenance nightmare. If we think a
> 64 bit port
> is a good idea, then lets create an sh64 directory and be done with it.
> Otherwise lets
> stick to sh5 as a new 32 architecture (since it is effectively a new
> machine).
>
> > Is this making sense to people?  We need your insights and suggestions
> > before we can make the formal proposal of SH-5 inclusion :).
> >
>
> Sort of, but I don't agree with you:-) I don't see the benefits, and I
> can see the problems.
>
> And also, I confess I am confused to exactly who you are going to make
> this formal proposal to. Could you explain this further?
>
> Cheers!
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev

Re: [linuxsh-dev] SH-5 integration issues

[David M. <dav...@st...>]

mr...@0x... wrote:
> 
> Paul and I have been trying to determine the best fit for the SH-5 port for
> 2.5.  The problem lies in the SH-5's (and SH-6's) addressing - it's 32-bit
> versus 64-bit, so the standard kernel convention for a 64-bit port doesn't
> necessarily qualify it as "sh64" (but hey, we're kernel hackers, we can
> bend the rules :P).

Well, I don't see any problem calling it a 64 bit. For me, the
fundamental criteria
for calling it a 64 bit port is that a pointer is 64 bits. This is
supported by the 
gcc toolchain (I've never tried it though), and all the internal
registers are quite 
happy with 64 bits. Yes, it is true that at the moment on the SH5 you
can't address more 
than 32 bits of physical, but I would view this as an implementation
detail, not an architecture 
restriction.  I agree that is a pain that the 64bitness is implemented
by sign extension
rather than real bits, but it is possible to build a kernel that would
work with this way 
of doing things and "real" 64 bits without too much pain I think.

Anyway, the current port isn't 64 bit, which is why it is an sh5
directory rather than
sh64. It should really be called shmedia in retrospect I suppose.

> Moving the SH-5 port in with the sh/ arch is a challenge

Absolutely. What I do not understand is what benefit you see from doing
it this way. 
As far as I can see it will simply make a mess of the current SH
support, as it is 
a different machine from an OS point of view.  Every arch specific file
will be duplicated, 
and will create an unholy mess for no benefit. Please explain what you
see as the benefits.


> is trying to plan for structuring future SH processors.  Will the SH-7 and
> SH-8 retain the SHmedia instructions and 32-bit addressing?  Or will
> Hitachi have a change of mind and switch to 64-bit addressing if the market
> calls for it?
> 

Rememeber that the architecture of future SH processors is controlled by
SuperH Inc,
not Hitachi. However, Hitachi and ourselves at ST can be safely
described as major customers 
of SuperH. I also think you have answered your own question, if somebody
wants a real 64 machine
I'm sure SuperH will be more than happy to oblige, given that the
architecture is already 64 bit 
so a 64 bit everywhere machine would be very easy for them to build. I
do not think they will
categorically state that they will never build a full 64 bit machine.
Anybody at superh care to 
comment?

As to SHmedia, I think that it is here to stay. It is the main
instructions set of 
the machine. A more pertinant question would be how long  SHcompact
stays around for.
Backward compatibilty costs both in terms of silicon area and
verification, so it is 
not beyond the realms of possibility that SuperH would produce a future
processor that 
is SHmedia only.  I can't speak for SuperH here, but it must be regarded
as a possibility.
Again I suspect that you will not get a statement saying SuperH will
always support
SHcompact in hardware indefinately for all future machines. Comments
from SuperH are invited.


> If future SH processors are "true" 64-bit machines (well addressing at
> least), then it makes sense for the SH-5 and SH-6 to live with the SH-3 and
> SH-4 code, but if the SH-7 and SH-8 retain current SHmedia and 32-bit
> addressing (e.g. they won't differ "externally" from the SH-5 or SH-6), then
> it makes sense for all SHmedia capable processors to live in "sh64".  This is
> why we need a bit of clarification (if at all possible) of the plans to stick
> with 32-bit addressing, so it'll potentially save us some work down the road.
> 

Again, I don't understand why you want to include sh5 code in
with the SH3/4 stuff. It will be a maintenance nightmare. If we think a
64 bit port
is a good idea, then lets create an sh64 directory and be done with it.
Otherwise lets 
stick to sh5 as a new 32 architecture (since it is effectively a new
machine). 

> Is this making sense to people?  We need your insights and suggestions
> before we can make the formal proposal of SH-5 inclusion :).
> 

Sort of, but I don't agree with you:-) I don't see the benefits, and I
can see the problems.

And also, I confess I am confused to exactly who you are going to make
this formal proposal to. Could you explain this further?

Cheers!

[linuxsh-dev] SH-5 integration issues

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

Paul and I have been trying to determine the best fit for the SH-5 port for
2.5.  The problem lies in the SH-5's (and SH-6's) addressing - it's 32-bit
versus 64-bit, so the standard kernel convention for a 64-bit port doesn't
necessarily qualify it as "sh64" (but hey, we're kernel hackers, we can
bend the rules :P).

Moving the SH-5 port in with the sh/ arch is a challenge, but the problem
is trying to plan for structuring future SH processors.  Will the SH-7 and
SH-8 retain the SHmedia instructions and 32-bit addressing?  Or will
Hitachi have a change of mind and switch to 64-bit addressing if the market
calls for it?

If future SH processors are "true" 64-bit machines (well addressing at
least), then it makes sense for the SH-5 and SH-6 to live with the SH-3 and
SH-4 code, but if the SH-7 and SH-8 retain current SHmedia and 32-bit
addressing (e.g. they won't differ "externally" from the SH-5 or SH-6), then
it makes sense for all SHmedia capable processors to live in "sh64".  This is
why we need a bit of clarification (if at all possible) of the plans to stick
with 32-bit addressing, so it'll potentially save us some work down the road.

Is this making sense to people?  We need your insights and suggestions
before we can make the formal proposal of SH-5 inclusion :).

Thanks,

M. R.

[linuxsh-dev] SH-5 Info

[<boy...@su...>]

Hi everyone,
=20
Following on from previous announcements we have placed the core =
architecture manuals for SH-5 on www.superh-software.com. In addition =
the ABI and asm syntax manuals have been tidied up and published too.
=20
In addition we built a Win2K version and have placed the binaries up =
there along with the sources. Note that this contains some items that =
aren't yet in the netsources - as I understand it the sim work hasn't =
been accepted, hence it will change from what is here.
=20
We are NOT requiring people to register - but we have further info to =
post up there. If you register we'll let you know about changes/updates =
to the software and documentation.
=20
Regards
Boyd
=20
=20

Re: [linuxsh-dev] SH5 kernel

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

Folks

I've uploaded a snapshot of the current SH5 tree to our FTP server:
  ftp://ftp.linuxsh.st.com/pub/linuxsh/sh5/linux-sh5-20020302.tar.bz2
for your perusal.

This is structured as a drop in tree, against a standard
linux-2.4.0-test4 tree.

At the moment I'm actually tempted to try putting this into a BitKeeper
project. As well as being an interesting test for BitKeeper, it has the
big plus for us of avoiding the problems we still have with CVS/ssh
through firewalls.

Any comments (on any of this), let me know.

Stuart

-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

[linuxsh-dev] Protect your vacation home against winter freeze for less than 30 cents a day!

[Doak S. <do...@th...>]

<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>The</title>
</head>

<body bgcolor="#FFFFFF" link="#FF0000" vlink="#00FFFF" alink="#FFFFFF">

<p style="margin-bottom: -10" align="center">&nbsp;</p>
<table border="1" style="border-collapse: collapse" bordercolor="#FFFFFF" width="58%" height="270">
  <tr>
    <td width="29%" height="180" nowrap bgcolor="#336699">
    <p style="margin-bottom: -25"><b><i><font size="5">&nbsp;</font><font size="6">The</font></i></b><p style="margin-bottom: -25">
    <b><i><font size="6">&nbsp;Cottage </font></i></b>
    <p style="margin-bottom: -25"><b><i><font size="6">&nbsp;Monitor</font></i></b><p style="margin-bottom: -25">&nbsp;<p style="margin-bottom: -25" align="center">
    <i>
    <b><font size="5">&nbsp;</font></b></i></td>
    <td width="81%" height="180" nowrap bgcolor="#336699">
    <p style="margin-bottom: -20" align="center">&nbsp;<p style="margin-bottom: -20" align="center">&nbsp;<p style="margin-bottom: -15" align="center"><font size="4" color="#FFFFFF">
    <i>CONTROL AND MONITOR THE </i></font>
    <p style="margin-bottom: -15" align="center"><font size="4" color="#FFFFFF">
    <i>TEMPERATURE IN YOUR </i></font>
    <p style="margin-bottom: -15" align="center"><font size="4" color="#FFFFFF">
    <i>VACATION HOME, 24 HOURS </i></font>
    <p style="margin-bottom: -15" align="center"><font size="4" color="#FFFFFF">
    <i>A DAY VIA A TOLL FREE </i></font>
    <p style="margin-bottom: -15" align="center"><font size="4" color="#FFFFFF">
    <i>TELEPHONE LINE!</i></font><p style="margin-bottom: -20" align="center">&nbsp;<p style="margin-bottom: -20" align="center">&nbsp;</td>
  </tr>
  <tr>
    <td width="100%" colspan="2" height="86" nowrap bgcolor="#336699">
    <p align="center" style="margin-bottom: -15"><br>
    <font size="4" color="#FFFFFF">Visit our web page in your location for
    further </font>
    <p align="center" style="margin-bottom: -15">
    <font color="#FFFFFF"><font size="4">information</font></font><p align="center" style="margin-bottom: -15">&nbsp;<p align="center" style="margin-bottom: -15">
    <font color="#FFFFFF">
    <a target="_blank" href="http://thecottagemonitor.com/California.htm">CALIFORNIA</a>&nbsp;
    <a target="_blank" href="http://thecottagemonitor.com/Colorado.htm">COLORADO&nbsp;</a>
    <a target="_blank" href="http://thecottagemonitor.com/index.htm">MICHIGAN</a>&nbsp;
    </font>
    <p align="center" style="margin-bottom: -15">
    <font color="#FFFFFF">
    <a target="_blank" href="http://thecottagemonitor.com/Minnesota.htm">MINNESOTA</a>&nbsp;
    <a href="http://thecottagemonitor.com/New%20York.htm">NEW YORK&nbsp; </a>
    </font>
    <p align="center" style="margin-bottom: -15">
    <font color="#FFFFFF">&nbsp;
    <a target="_blank" href="http://thecottagemonitor.com/Utah.htm">UTAH</a>&nbsp; </font><p align="center" style="margin-bottom: -15">&nbsp;<p align="center" style="margin-bottom: -15">
    <font size="5">800.549.9276</font><p align="center" style="margin-bottom: -15">
    <a href="mailto:in...@th...">in...@th...</a><p align="center" style="margin-bottom: -15">&nbsp;</td>
  </tr>
</table>
<p style="margin-bottom: -10" align="center">&nbsp;</p>

</body>

</html>

[linuxsh-dev] problem in networking with ASPEN SH7750

[Deepak K. G. <dk...@no...>]

> Hello List,
> 
> I am using ASPEN SH7750 base board from Hitachi, with TAHOE Q2SD daughter
> board. My computer (P-3) and ASPEN board are connected using serial port
> (DMON console). Also an ethernet cable is connected on Dbg Eth of ASPEN
> board and my computer 
> 
> I am able to boot the board successfully, but when I try to ping to/from
> board, it displays the error message "sendto: host is down". It is
> interesting that few days back it was working correctly. But now it is not
> working. I don't know the reason of problem.
> 
> When I unplug the ethernet cable, the message displays "Link is down" and
> when I reconnect it the message displayed is "Link is up". The led on Eth
> port indicates the activity on port.
> 
> I have settled and verified all the parameters for networking (IP
> addresses etc.) correctly.
> 
> Is there any mechanism/setting in hardware to due to which the controller
> is not responding ? The manual doesn't have any such information.
> 
> The details of controller and driver are as follows: 
> 
> Mode = 100BTHD
> SMC9000
> 
> Vendor..............0x0
> Device...............0x8
> Revision.............0x0
> I/O Port Base....0x4400300
> Interrupt............0x2
> 
> Can anybody help me in this regard ?
> 
> Please CC the reply to me also, as I am not member of list.
> 
> Thanks in advance.
> Deepak.

Re: [linuxsh-dev] Tasklets in 2.4.18^H7

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

On Thursday 07 Mar 2002 12:19 am, Adrian McMenamin wrote:
......

My apologies this should have been 2.4.17

[linuxsh-dev] Tasklets in 2.4.18

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

This problem is quite likely to be down to me (either poor coding or 
understanding of kernel API), but I have sufficient doubt as to ask.

I have been implementing a device driver for the Dreamcast and have been 
using tasklets.

The device is meant to be hot pluggable and so I was enabling the tasklet as 
deevices were plugged in.

However, this appeared to break after being enabled more than once - ie when 
first device was plugged in was fine, but when second or more devices were 
plugged in the tasklet was never scheduled (ie run, the actual 
tasklet_schedule call was still being made) at all.

Is this a known problem, or have I missed something in how the tasklet API 
works?

Adrian

[linuxsh-dev] problem in networking with ASPEN SH7750

[Deepak K. G. <dk...@no...>]

Hello List,

I am using ASPEN SH7750 base board from Hitachi, with TAHOE Q2SD daughter
board. My computer (P-3) and ASPEN board are connected using serial port
(DMON console). Also an ethernet cable is connected on Dbg Eth of ASPEN
board and my computer 

I am able to boot the board successfully, but when I try to ping to/from
board, it displays the error message "sendto: host is down". It is
interesting that few days back it was working correctly. But now it is not
working. I don't know the reason of problem.

When I unplug the ethernet cable, the message displays "Link is down" and
when I reconnect it the message displayed is "Link is up". The led on Eth
port indicates the activity on port.

I have settled and verified all the parameters for networking (IP addresses
etc.) correctly.

Is there any mechanism/setting in hardware to due to which the controller is
not responding ? The manual doesn't have any such information.

The details of controller and driver are as follows: 

Mode = 100BTHD
SMC9000

Vendor..............0x0
Device...............0x8
Revision.............0x0
I/O Port Base....0x4400300
Interrupt............0x2

Can anybody help me in this regard ?

Please CC the reply to me also, as I am not member of list.

Thanks in advance.
Deepak.

[linuxsh-dev] 2.5.4 (still partial)

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

Follow up to 2.5.4.

Introducing thread_info structure.  Will come correspoinding change
of entry.S...

Note that we won't have addr_limit member for thread_info.
This should be fit in a cache line (or it's better), and SH-3 has only
has 16-byte.

2002-03-05  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/kernel/fpu.c (save_fpu, ieee_fpe_handler,
	do_fpu_state_restore): Use set_tsk_thread_flag and
	clear_tsk_thread_flag.

	* arch/sh/kernel/process.c (print_syscall): Removed.

	* include/asm-sh/processor.h (thread_saved_pc): Follow the change
	of API (argument type).
	(THREAD_SIZE): Removed from here (will be in thread_info.h).
	(alloc_task_struct, free_task_struct, get_task_struct, init_task,
	init_stack): Removed.
	(unlazy_fpu, clear_fpu): Use test_tsk_thread_flag and
	clear_tsk_thread_flag.

	* include/asm-sh/uaccess.h (KERN_ADDR_LIMIT, USER_ADDR_LIMIT): New
	macros.
	(KERNEL_DS, USER_DS): Use KERN_ADDR_LIMIT, USER_ADDR_LIMIT.
	(get_fs, set_fs): New functions using thread flag.
	(__addr_ok, __range_ok): Use get_fs().seg.

	* include/asm-sh/thread_info.h: New file.

Index: arch/sh/kernel/fpu.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/fpu.c,v
retrieving revision 1.3
diff -u -3 -p -r1.3 fpu.c
--- arch/sh/kernel/fpu.c	1 Mar 2002 01:55:10 -0000	1.3
+++ arch/sh/kernel/fpu.c	5 Mar 2002 09:01:58 -0000
@@ -67,7 +67,7 @@ save_fpu(struct task_struct *tsk)
 		       "r" (FPSCR_INIT)
 		     : "memory");
 
-	clear_thread_flag(TIF_USEDFPU);
+	clear_tsk_thread_flag(tsk, TIF_USEDFPU);
 	release_fpu();
 }
 
@@ -260,7 +260,7 @@ ieee_fpe_handler (struct pt_regs *regs)
 				~(FPSCR_CAUSE_MASK | FPSCR_FLAG_MASK);
 			grab_fpu();
 			restore_fpu(tsk);
-			set_thread_flag(TIF_USEDFPU);
+			set_tsk_thread_flag(tsk, TIF_USEDFPU);
 		} else {
 			tsk->thread.trap_no = 11;
 			tsk->thread.error_code = 0;
@@ -310,5 +310,5 @@ do_fpu_state_restore(unsigned long r4, u
 		fpu_init();
 		tsk->used_math = 1;
 	}
-	set_thread_flag(TIF_USEDFPU);
+	set_tsk_thread_flag(tsk, TIF_USEDFPU);
 }
Index: arch/sh/kernel/process.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/arch/sh/kernel/process.c,v
retrieving revision 1.4
diff -u -3 -p -r1.4 process.c
--- arch/sh/kernel/process.c	24 Jan 2002 11:22:36 -0000	1.4
+++ arch/sh/kernel/process.c	5 Mar 2002 09:01:58 -0000
@@ -355,17 +355,6 @@ unsigned long get_wchan(struct task_stru
 	return pc;
 }
 
-asmlinkage void print_syscall(int x)
-{
-	unsigned long flags, sr;
-	asm("stc	sr, %0": "=r" (sr));
-	save_and_cli(flags);
-	printk("%c: %c %c, %c: SYSCALL\n", (x&63)+32,
-	       (current->flags&PF_USEDFPU)?'C':' ',
-	       (init_task.flags&PF_USEDFPU)?'K':' ', (sr&SR_FD)?' ':'F');
-	restore_flags(flags);
-}
-
 asmlinkage void break_point_trap(unsigned long r4, unsigned long r5,
 				 unsigned long r6, unsigned long r7,
 				 struct pt_regs regs)
Index: include/asm-sh/processor.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/processor.h,v
retrieving revision 1.2
diff -u -3 -p -r1.2 processor.h
--- include/asm-sh/processor.h	29 Dec 2001 06:50:38 -0000	1.2
+++ include/asm-sh/processor.h	5 Mar 2002 09:01:58 -0000
@@ -182,17 +182,17 @@ static __inline__ void grab_fpu(void)
 
 extern void save_fpu(struct task_struct *__tsk);
 
-#define unlazy_fpu(tsk) do { 			\
-	if ((tsk)->flags & PF_USEDFPU) {	\
-		save_fpu(tsk); 			\
-	}					\
+#define unlazy_fpu(tsk) do { 				\
+	if (test_tsk_thread_flag(tsk, TIF_USEDFPU)) {	\
+		save_fpu(tsk); 				\
+	}						\
 } while (0)
 
-#define clear_fpu(tsk) do { 			\
-	if ((tsk)->flags & PF_USEDFPU) { 	\
-		(tsk)->flags &= ~PF_USEDFPU; 	\
-		release_fpu();			\
-	}					\
+#define clear_fpu(tsk) do { 					\
+	if (test_tsk_thread_flag(tsk, TIF_USEDFPU)) { 		\
+		clear_tsk_thread_flag(tsk, TIF_USEDFPU); 	\
+		release_fpu();					\
+	}							\
 } while (0)
 
 /* Double presision, NANS as NANS, rounding to nearest, no exceptions */
@@ -204,23 +204,15 @@ extern void save_fpu(struct task_struct 
 /*
  * Return saved PC of a blocked thread.
  */
-static __inline__ unsigned long thread_saved_pc(struct thread_struct *t)
+static __inline__ unsigned long thread_saved_pc(struct task_struct *tsk)
 {
-	return t->pc;
+	return tsk->thread->pc;
 }
 
 extern unsigned long get_wchan(struct task_struct *p);
 
 #define KSTK_EIP(tsk)  ((tsk)->thread.pc)
 #define KSTK_ESP(tsk)  ((tsk)->thread.sp)
-
-#define THREAD_SIZE (2*PAGE_SIZE)
-extern struct task_struct * alloc_task_struct(void);
-extern void free_task_struct(struct task_struct *);
-#define get_task_struct(tsk)      atomic_inc(&virt_to_page(tsk)->count)
-
-#define init_task	(init_task_union.task)
-#define init_stack	(init_task_union.stack)
 
 #define cpu_relax()	do { } while (0)
 
Index: include/asm-sh/thread_info.h
===================================================================
RCS file: include/asm-sh/thread_info.h
diff -N include/asm-sh/thread_info.h
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ include/asm-sh/thread_info.h	5 Mar 2002 09:01:58 -0000
@@ -0,0 +1,110 @@
+#ifndef __ASM_SH_THREAD_INFO_H
+#define __ASM_SH_THREAD_INFO_H
+
+/* SuperH version
+ * Copyright (C) 2002  Niibe Yutaka
+ *
+ * The copyright of original i386 version is:
+ *
+ *  Copyright (C) 2002  David Howells (dho...@re...)
+ *  - Incorporating suggestions made by Linus Torvalds and Dave Miller
+ */
+
+#ifdef __KERNEL__
+
+#ifndef __ASSEMBLY__
+#include <asm/processor.h>
+#endif
+
+/*
+ * low level task data that entry.S needs immediate access to
+ * - this struct should fit entirely inside of one cache line
+ * - this struct shares the supervisor stack pages
+ * - if the contents of this structure are changed, the assembly constants must also be changed
+ */
+#ifndef __ASSEMBLY__
+struct thread_info {
+	struct task_struct	*task;		/* main task structure */
+	struct exec_domain	*exec_domain;	/* execution domain */
+	__u32			flags;		/* low level flags */
+	__s32			preempt_count; /* 0 => preemptable, <0 => BUG */
+
+	__u8			supervisor_stack[0];
+};
+
+#else /* !__ASSEMBLY__ */
+
+/* offsets into the thread_info struct for assembly code access */
+#define TI_TASK		0x00000000
+#define TI_EXEC_DOMAIN	0x00000004
+#define TI_FLAGS	0x00000008
+#define TI_PRE_COUNT	0x0000000c
+
+#endif
+
+/*
+ * macros/functions for gaining access to the thread information structure
+ */
+#ifndef __ASSEMBLY__
+#define INIT_THREAD_INFO(tsk)			\
+{						\
+	task:		&tsk,			\
+	exec_domain:	&default_exec_domain,	\
+	flags:		0,			\
+	preempt_count:	0,			\
+}
+
+#define init_thread_info	(init_thread_union.thread_info)
+#define init_stack		(init_thread_union.stack)
+
+/* how to get the thread information struct from C */
+static inline struct thread_info *current_thread_info(void)
+{
+	struct thread_info *ti;
+	__asm__("stc	r7_bank, %0" : "=r" (ti));
+	return ti;
+}
+
+/* thread information allocation */
+#define THREAD_SIZE (2*PAGE_SIZE)
+#define alloc_thread_info() ((struct thread_info *) __get_free_pages(GFP_KERNEL,1))
+#define free_thread_info(ti) free_pages((unsigned long) (ti), 1)
+#define get_thread_info(ti) get_task_struct((ti)->task)
+#define put_thread_info(ti) put_task_struct((ti)->task)
+
+#else /* !__ASSEMBLY__ */
+
+/* how to get the thread information struct from ASM */
+#define GET_THREAD_INFO(reg) \
+	stc	r7_bank, reg
+
+#endif
+
+/*
+ * thread information flags
+ * - these are process state flags that various assembly files may need to access
+ * - pending work-to-be-done flags are in LSW
+ * - other flags in MSW
+ */
+#define TIF_SYSCALL_TRACE	0	/* syscall trace active */
+#define TIF_NOTIFY_RESUME	1	/* resumption notification requested */
+#define TIF_SIGPENDING		2	/* signal pending */
+#define TIF_NEED_RESCHED	3	/* rescheduling necessary */
+#define TIF_USEDFPU		16	/* FPU was used by this task this quantum (SMP) */
+#define TIF_POLLING_NRFLAG	17	/* true if poll_idle() is polling TIF_NEED_RESCHED */
+#define TIF_USERSPACE		18	/* true if FS sets userspace */
+
+#define _TIF_SYSCALL_TRACE	(1<<TIF_SYSCALL_TRACE)
+#define _TIF_NOTIFY_RESUME	(1<<TIF_NOTIFY_RESUME)
+#define _TIF_SIGPENDING		(1<<TIF_SIGPENDING)
+#define _TIF_NEED_RESCHED	(1<<TIF_NEED_RESCHED)
+#define _TIF_USEDFPU		(1<<TIF_USEDFPU)
+#define _TIF_POLLING_NRFLAG	(1<<TIF_POLLING_NRFLAG)
+#define _TIF_USERSPACE		(1<<TIF_USERSPACE)
+
+#define _TIF_WORK_MASK		0x0000FFFE	/* work to do on interrupt/exception return */
+#define _TIF_ALLWORK_MASK	0x0000FFFF	/* work to do on any return to u-space */
+
+#endif /* __KERNEL__ */
+
+#endif /* __ASM_SH_THREAD_INFO_H */
Index: include/asm-sh/uaccess.h
===================================================================
RCS file: /cvsroot/linuxsh/linux/include/asm-sh/uaccess.h,v
retrieving revision 1.3
diff -u -3 -p -r1.3 uaccess.h
--- include/asm-sh/uaccess.h	1 Mar 2002 01:55:10 -0000	1.3
+++ include/asm-sh/uaccess.h	5 Mar 2002 09:01:58 -0000
@@ -28,16 +28,33 @@
 
 #define MAKE_MM_SEG(s)	((mm_segment_t) { (s) })
 
-#define KERNEL_DS	MAKE_MM_SEG(0xFFFFFFFF)
-#define USER_DS		MAKE_MM_SEG(0x80000000)
+#define KERN_ADDR_LIMIT	0xFFFFFFFF
+#define USER_ADDR_LIMIT	0x80000000
+
+#define KERNEL_DS	MAKE_MM_SEG(KERN_ADDR_LIMIT)
+#define USER_DS		MAKE_MM_SEG(USER_ADDR_LIMIT)
 
 #define get_ds()	(KERNEL_DS)
-#define get_fs()        (current_thread_info()->addr_limit)
-#define set_fs(x)       (current_thread_info()->addr_limit=(x))
+
+static inline mm_segment_t get_fs(void)
+{
+	if (test_thread_flag(TIF_USERSPACE))
+		return USER_DS;
+	else
+		return KERNEL_DS;
+}
+
+static inline void set_fs(mm_segment_t s)
+{
+	if (s.seg == USER_ADDR_LIMIT)
+		set_thread_flag(TIF_USERSPACE);
+	else
+		clear_thread_flag(TIF_USERSPACE);
+}
 
 #define segment_eq(a,b)	((a).seg == (b).seg)
 
-#define __addr_ok(addr) ((unsigned long)(addr) < (current_thread_info()->addr_limit.seg))
+#define __addr_ok(addr) ((unsigned long)(addr) < (get_fs().seg))
 
 /*
  * Uhhuh, this needs 33-bit arithmetic. We have a carry..
@@ -49,7 +66,7 @@
 	unsigned long flag,sum; 					      \
 	__asm__("clrt; addc %3, %1; movt %0; cmp/hi %4, %1; rotcl %0"	      \
 		:"=&r" (flag), "=r" (sum) 				      \
-		:"1" (addr), "r" ((int)(size)), "r" (current_thread_info()->addr_limit.seg) \
+		:"1" (addr), "r" ((int)(size)), "r" (get_fs().seg) \
 		:"t"); 							      \
 	flag; })
 

[linuxsh-dev] Re: Running TMU1

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

Hi Jeremy,

I've attached our code in RTLinux-sh where manipulates TMU0 and 1. I use
TMU1 as free running timer, same as your code does, but additionally we
check if TMU1 has wrapped (0->0xffffffff) periodically.

You may notice by looking at our code that we implemented mechanism to
get time since machine boot, using TMU1. ("_shtimer_gettime()" returns
nanoseconds since machine boot)

I think your code require RTLinux-sh some adjustments, but it won't
break the mechanism. Adjustment shouldn't be much. I don't say your code
"conflicts" with ours, but rather "require tweaks". (I'm afraid if I'm
not giving you the right words to express my thinking).

Attached rtl_time.c forms part of kernel module, so your code uses TMU1
earlier than rtl_time.c do. I don't think you need to check the usage of
the timer, but our code do.

If you have time, please take a look at our code, and tell me your
impression on how those two codes can coexist together.

(As a side note, RTLinux-sh takeover TMU0 also. It is no longer simple
periodic timer, but reprogrammed every time the interrupt occur, to wake
up the real-time task.)

On Thu, 28 Feb 2002 14:05:50 -0800
Jeremy Siegel <js...@mv...> wrote:

> I'd like to include the following timer.c patch to set up TMU1 as a
> free-running timer for timestamp or instrumentation purposes (or maybe a
> future port of hi-res timers to the SH kernel).  This'll be in our
> distribution under ifdefs specific to features that use it; in this patch
> it's just under CONFIG_START_TMU1 since that seemed more general (could be
> turned on by features needing it).  [I've also attached a modified
> preem_latency.h file, just as an example of how it'd be used; it seems
> simpler than what's currently in the preempt_stats patch for SH.]
> 
> To Masahiro Abe: is this usage similar enough to your usage in RT-Linux
> that it doesn't conflict?  Would it help to
> put the startup code under a conditional check on whether the timer has
> already been activated?
> 
> Last month I sent out a query about this, and one question I had was that
> even TMU0 seems to be running faster
> than the specs allow, and I've been running both TMU1 and TMU0 at the same
> speed w/o apparent problems yet...
> again, I'm assuming that aspect of the spec is incorrect (irrelvant to
> SH3/SH4) but if that's a bad assumption
> please let me know!
> 
> Any objections to the timer.c change?
> 
> Thanks,
>   --Jeremy Siegel

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

Re: [linuxsh-dev] SH5 kernel

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

On Fri, 1 Mar 2002 05:43:01 -0600
mr...@0x... wrote:

> * Stuart Menefy <stu...@st...> on Fri, Mar 01, 2002:
> 
> > 
> > As far as I know the only reference boards are from Hitachi:
> >   ftp://ftp.hitachi.com/netshare/capp01/Cayman/
> > I have one, through SuperH, but whether they are 'available' I don't know.
> > 
> 
> Hmm, is this the correct link?  ftp.hitachi.com doesn't resolve....

Apologies, that should have been:
  http://ftp.hsa.hitachi.com/netshare/capp01/Cayman/

Stuart

-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

Re: [linuxsh-dev] SH5 kernel

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

* Stuart Menefy <stu...@st...> on Fri, Mar 01, 2002:

>=20
> As far as I know the only reference boards are from Hitachi:
>   ftp://ftp.hitachi.com/netshare/capp01/Cayman/
> I have one, through SuperH, but whether they are 'available' I don't know.
>=20

Hmm, is this the correct link?  ftp.hitachi.com doesn't resolve....

M. R.

Re: [linuxsh-dev] SH5 kernel

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

On Thu, 28 Feb 2002 14:55:10 -0800
le...@Ch... wrote:

> On Thu, Feb 28, 2002 at 09:59:58PM +0000, Stuart Menefy wrote:
> > Short answer, I've no idea. SH8000 is Hitachi's part (and as fasr as I know
> > is the only chip with an SH5 core at the moment).
> > 
> So how does this relate to reference hardware? Does everyone have to go
> through Hitachi for reference hardware? And what about ST50, is there anything
> special about that? or hardware?

As far as I know the only reference boards are from Hitachi:
  ftp://ftp.hitachi.com/netshare/capp01/Cayman/
I have one, through SuperH, but whether they are 'available' I don't know.

ST50 is ST's name for parts with an SH5 core. Currently there are none,
all SH5 based parts have been fabed by Hitachi.

> > > Either way.. lets have a look at the tree first, and then we can figure out
> > > what the best course of action might be. Or if anyone else has any similar
> > > insight on the matter, that could be helpful too.
> > > 
> > 
> > OK, so how about before we go any further I post it on an FTP server
> > first, and then we can have a more informed discussion?
> > 
> Sounds like a plan.

Watch this space...

Stuart

-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com