linuxsh-dev

[linuxsh-dev] [PATCH] fix compressed head.S

[Philipp R. <pr...@pa...>]

This should make compressed kernels work on more machines, please apply.

2000-12-24  Philipp Rumpf <pr...@tu...>
	* arch/sh/boot/compressed/head.S (init_sr): initialize imask to 15

diff -urNx CVS linuxsh/kernel/arch/sh/boot/compressed/head.S linux-aero/arch/sh/boot/compressed/head.S
--- linuxsh/kernel/arch/sh/boot/compressed/head.S	Sun Dec 24 10:43:53 2000
+++ linux-aero/arch/sh/boot/compressed/head.S	Sun Dec 24 10:45:01 2000
@@ -43,7 +43,7 @@
 end_addr:
 	.long	_end
 init_sr:
-	.long	0x40000000	/* Privileged mode, Bank=0, Block=0, I3-I0=0 */
+	.long	0x400000F0	/* Privileged mode, Bank=0, Block=0, IMASK=0xF */
 init_stack_addr:
 	.long	stack_start
 decompress_kernel_addr:

[linuxsh-dev] [PATCH] fix compressed head.S

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

Philipp Rumpf wrote:
 > 2000-12-24  Philipp Rumpf <pr...@tu...>
 > 	* arch/sh/boot/compressed/head.S (init_sr): initialize imask to 15
[...]
 > 2000-12-24  Philipp Rumpf <pr...@tu...>
 > 	* arch/sh/kernel/fpu.c: Remove '$' for register specification.

Thanks, installed.

Greg has merged 2.4.0-test12 changes, and I did for 2.4.0-test13-pre4.
I'll include changes of RTC issues.

I'm not up to date for the things about alignment handling.  If I
remember correctly, current CVS version is a sort of "very kind" for
user space than it should be.

Sending patches to Linus one by one...
-- 

[linuxsh-dev] .initcall alignment

[Bill M. <bi...@bi...>]

Having a problem with the initialization functions called from this
proceedure located in kernel/init/main.c

static void __init do_initcalls(void)
{
	initcall_t *call;

	call = &__initcall_start;
	do {
		(*call)();
		call++;
	} while (call < &__initcall_end);
}

A sample of the mapfile bracketed by symbols __initcall_start &
__initcall_end is allocated so:

8c10cc90 ? .initcal
8c10cc90 ? __initcall_kswapd_init
8c10cc90 A __initcall_start
8c10cc90 A __setup_end
8c10cca0 ? .initcal
8c10cca0 ? __initcall_bdflush_init
	-
	-
	-
8c10cd30 A __initcall_end

My problem is that the above proceedure increments "call" by 4 but the function
pointers which are positioned between __initcall_start .. end, "__initcall_kswapd_init" & "__initcall_bdflush_init", are allocated 
0x10 bytes apart and execution results expectedly in "Address Error".  

Suggestions?

[linuxsh-dev] HP Jornada 545

[Edgar H. <hos...@ed...>]

Hi.

Is there a way to use linuxsh on the
HP Jornada 545. If there is a way, what mußt
i do exactly.

mfg

ED.

-------------------------------------------
Whoa...I did a 'zcat /vmlinuz > /dev/audio'
and I think I heard God...
-------------------------------------------
We have joy, we have fun, we use LINUX on
a Sun ;-))
-------------------------------------------

[linuxsh-dev] [PATCH] RTC cleanup/generalization

[Philipp R. <pr...@pa...>]

This should allow us to merge the DC RTC support nicely

2000-12-11  Philipp Rumpf <pr...@tu...>
	* arch/sh/kernel/rtc.c, include/asm-sh/rtc.h: New files.

	* arch/sh/config.in [CONFIG_SH_RTC]: made SH onchip RTC support
	conditional.
	* arch/sh/kernel/Makefile [CONFIG_SH_RTC]: Likewise.
	* arch/sh/kernel/mach_foobar.c, arch/sh/kernel/mach_se.c,
	arch/sh/kernel/mach_hp600.c, arch/sh/kernel/mach_unknown.c: Likewise.

	* arch/sh/kernel/time.c (get_timer_frequency): modified to work with
	non-standard RTCs.
	(do_timer_interrupt): Likewise.
	(set_rtc_time) (get_rtc_time): removed functions

diff -urNx CVS linuxsh/kernel/arch/sh/config.in linux-aero/arch/sh/config.in
--- linuxsh/kernel/arch/sh/config.in	Fri Dec  8 13:30:10 2000
+++ linux-aero/arch/sh/config.in	Mon Dec 11 05:12:10 2000
@@ -33,11 +33,18 @@
 	 HP690			CONFIG_SH_HP690			\
 	 CqREEK			CONFIG_SH_CQREEK		\
 	 FOOBAR			CONFIG_SH_FOOBAR    		\
+	 EC3104			CONFIG_SH_EC3104		\
 	 BareCPU		CONFIG_SH_UNKNOWN" Generic
 
 if [ "$CONFIG_SH_HP620" = "y" -o "$CONFIG_SH_HP680" = "y" -o \
      "$CONFIG_SH_HP690" = "y" ]; then
 	define_bool CONFIG_SH_HP600 y
+fi
+
+if [ "$CONFIG_SH_DREAMCAST" = "y" ]; then
+   define_bool CONFIG_DREAMCAST_RTC y
+else
+   define_bool CONFIG_SH_RTC y
 fi
 
 choice 'Processor type' \
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/Makefile linux-aero/arch/sh/kernel/Makefile
--- linuxsh/kernel/arch/sh/kernel/Makefile	Fri Dec  8 13:30:11 2000
+++ linux-aero/arch/sh/kernel/Makefile	Mon Dec 11 05:12:30 2000
@@ -20,6 +20,10 @@
 O_OBJS += cf-enabler.o
 endif
 
+ifdef CONFIG_SH_RTC
+O_OBJS += rtc.o
+endif
+
 ifneq ($(CONFIG_SH_GENERIC)$(CONFIG_SH_HP600),)
 O_OBJS += mach_hp600.o io_hd64461.o
 endif
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/mach_foobar.c linux-aero/arch/sh/kernel/mach_foobar.c
--- linuxsh/kernel/arch/sh/kernel/mach_foobar.c	Mon Dec 11 06:30:04 2000
+++ linux-aero/arch/sh/kernel/mach_foobar.c	Mon Dec 11 05:07:16 2000
@@ -16,6 +16,7 @@
 #include <linux/init.h>
 
 #include <asm/machvec.h>
+#include <asm/rtc.h>
 #include <asm/machvec_init.h>
 
 #include <asm/io.h>
@@ -60,6 +61,9 @@
 	mv_writel:		generic_writel,
 
 	mv_irq_demux:		hd64465_irq_demux,
+
+	mv_rtc_gettimeofday:	sh_rtc_gettimeofday,
+	mv_rtc_settimeofday:	sh_rtc_settimeofday,
 
 	mv_hw_hd64465:		1,
 };
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/mach_hp600.c linux-aero/arch/sh/kernel/mach_hp600.c
--- linuxsh/kernel/arch/sh/kernel/mach_hp600.c	Mon Dec 11 06:30:04 2000
+++ linux-aero/arch/sh/kernel/mach_hp600.c	Mon Dec 11 05:06:57 2000
@@ -12,6 +12,7 @@
 #include <linux/init.h>
 
 #include <asm/machvec.h>
+#include <asm/rtc.h>
 #include <asm/machvec_init.h>
 
 #include <asm/io_hd64461.h>
@@ -57,6 +58,9 @@
 
 	mv_irq_demux:		hd64461_irq_demux,
 
+	mv_rtc_gettimeofday:	sh_rtc_gettimeofday,
+	mv_rtc_settimeofday:	sh_rtc_settimeofday,
+
 	mv_hw_hp600:		1,
 	mv_hw_hp620:		1,
 	mv_hw_hd64461:		1,
@@ -99,6 +103,9 @@
 
 	mv_irq_demux:		hd64461_irq_demux,
 
+	mv_rtc_gettimeofday:	sh_rtc_gettimeofday,
+	mv_rtc_settimeofday:	sh_rtc_settimeofday,
+
 	mv_hw_hp600:		1,
 	mv_hw_hp680:		1,
 	mv_hw_hd64461:		1,
@@ -140,6 +147,9 @@
 	mv_writel:		generic_writel,
 
 	mv_irq_demux:		hd64461_irq_demux,
+
+	mv_rtc_gettimeofday:	sh_rtc_gettimeofday,
+	mv_rtc_settimeofday:	sh_rtc_settimeofday,
 
 	mv_hw_hp600:		1,
 	mv_hw_hp690:		1,
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/mach_se.c linux-aero/arch/sh/kernel/mach_se.c
--- linuxsh/kernel/arch/sh/kernel/mach_se.c	Mon Dec 11 06:30:04 2000
+++ linux-aero/arch/sh/kernel/mach_se.c	Mon Dec 11 05:07:46 2000
@@ -13,6 +13,7 @@
 #include <linux/init.h>
 
 #include <asm/machvec.h>
+#include <asm/rtc.h>
 #include <asm/machvec_init.h>
 
 #include <asm/io_se.h>
@@ -74,6 +75,9 @@
 #ifdef CONFIG_HEARTBEAT
 	mv_heartbeat:		heartbeat_se,
 #endif
+
+	mv_rtc_gettimeofday:	sh_rtc_gettimeofday,
+	mv_rtc_settimeofday:	sh_rtc_settimeofday,
 
 	mv_hw_se:		1,
 };
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/mach_unknown.c linux-aero/arch/sh/kernel/mach_unknown.c
--- linuxsh/kernel/arch/sh/kernel/mach_unknown.c	Mon Dec 11 06:30:04 2000
+++ linux-aero/arch/sh/kernel/mach_unknown.c	Mon Dec 11 05:08:17 2000
@@ -64,5 +64,8 @@
 	mv_iounmap:		unknown_iounmap,
 
 	mv_isa_port2addr:	unknown_isa_port2addr,
+
+	mv_rtc_gettimeofday:	sh_rtc_gettimeofday,
+	mv_rtc_settimeofday:	sh_rtc_settimeofday,
 };
 ALIAS_MV(unknown)
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/rtc.c linux-aero/arch/sh/kernel/rtc.c
--- linuxsh/kernel/arch/sh/kernel/rtc.c	Wed Dec 31 16:00:00 1969
+++ linux-aero/arch/sh/kernel/rtc.c	Mon Dec 11 05:28:51 2000
@@ -0,0 +1,178 @@
+/*
+ * linux/arch/sh/kernel/rtc.c -- SH3 / SH4 on-chip RTC support
+ *
+ *  Copyright (C) 2000  Philipp Rumpf <pr...@tu...>
+ *  Copyright (C) 1999  Tetsuya Okada & Niibe Yutaka
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/time.h>
+
+#include <asm/io.h>
+#include <asm/rtc.h>
+
+/* RCR1 Bits */
+#define RCR1_CF		0x80	/* Carry Flag             */
+#define RCR1_CIE	0x10	/* Carry Interrupt Enable */
+#define RCR1_AIE	0x08	/* Alarm Interrupt Enable */
+#define RCR1_AF		0x01	/* Alarm Flag             */
+
+/* RCR2 Bits */
+#define RCR2_PEF	0x80	/* PEriodic interrupt Flag */
+#define RCR2_PESMASK	0x70	/* Periodic interrupt Set  */
+#define RCR2_RTCEN	0x08	/* ENable RTC              */
+#define RCR2_ADJ	0x04	/* ADJustment (30-second)  */
+#define RCR2_RESET	0x02	/* Reset bit               */
+#define RCR2_START	0x01	/* Start bit               */
+
+
+#if defined(__sh3__)
+/* SH-3 RTC */
+#define R64CNT  	0xfffffec0
+#define RSECCNT 	0xfffffec2
+#define RMINCNT 	0xfffffec4
+#define RHRCNT  	0xfffffec6
+#define RWKCNT  	0xfffffec8
+#define RDAYCNT 	0xfffffeca
+#define RMONCNT 	0xfffffecc
+#define RYRCNT  	0xfffffece
+#define RSECAR  	0xfffffed0
+#define RMINAR  	0xfffffed2
+#define RHRAR   	0xfffffed4
+#define RWKAR   	0xfffffed6
+#define RDAYAR  	0xfffffed8
+#define RMONAR  	0xfffffeda
+#define RCR1    	0xfffffedc
+#define RCR2    	0xfffffede
+#elif defined(__SH4__)
+/* SH-4 RTC */
+#define R64CNT  	0xffc80000
+#define RSECCNT 	0xffc80004
+#define RMINCNT 	0xffc80008
+#define RHRCNT  	0xffc8000c
+#define RWKCNT  	0xffc80010
+#define RDAYCNT 	0xffc80014
+#define RMONCNT 	0xffc80018
+#define RYRCNT  	0xffc8001c  /* 16bit */
+#define RSECAR  	0xffc80020
+#define RMINAR  	0xffc80024
+#define RHRAR   	0xffc80028
+#define RWKAR   	0xffc8002c
+#define RDAYAR  	0xffc80030
+#define RMONAR  	0xffc80034
+#define RCR1    	0xffc80038
+#define RCR2    	0xffc8003c
+#endif
+
+#ifndef BCD_TO_BIN
+#define BCD_TO_BIN(val) ((val)=((val)&15) + ((val)>>4)*10)
+#endif
+
+#ifndef BIN_TO_BCD
+#define BIN_TO_BCD(val) ((val)=(((val)/10)<<4) + (val)%10)
+#endif
+
+void sh_rtc_gettimeofday(struct timeval *tv)
+{
+	unsigned int sec128, sec, min, hr, wk, day, mon, yr, yr100;
+
+ again:
+	do {
+		ctrl_outb(0, RCR1);  /* Clear CF-bit */
+		sec128 = ctrl_inb(RSECCNT);
+		sec = ctrl_inb(RSECCNT);
+		min = ctrl_inb(RMINCNT);
+		hr  = ctrl_inb(RHRCNT);
+		wk  = ctrl_inb(RWKCNT);
+		day = ctrl_inb(RDAYCNT);
+		mon = ctrl_inb(RMONCNT);
+#if defined(__SH4__)
+		yr  = ctrl_inw(RYRCNT);
+		yr100 = (yr >> 8);
+		yr &= 0xff;
+#else
+		yr  = ctrl_inb(RYRCNT);
+		yr100 = (yr == 0x99) ? 0x19 : 0x20;
+#endif
+	} while ((ctrl_inb(RCR1) & RCR1_CF) != 0);
+
+	BCD_TO_BIN(yr100);
+	BCD_TO_BIN(yr);
+	BCD_TO_BIN(mon);
+	BCD_TO_BIN(day);
+	BCD_TO_BIN(hr);
+	BCD_TO_BIN(min);
+	BCD_TO_BIN(sec);
+
+	if (yr > 99 || mon < 1 || mon > 12 || day > 31 || day < 1 ||
+	    hr > 23 || min > 59 || sec > 59) {
+		printk(KERN_ERR
+		       "SH RTC: invalid value, resetting to 1 Jan 2000\n");
+		ctrl_outb(RCR2_RESET, RCR2);  /* Reset & Stop */
+		ctrl_outb(0, RSECCNT);
+		ctrl_outb(0, RMINCNT);
+		ctrl_outb(0, RHRCNT);
+		ctrl_outb(6, RWKCNT);
+		ctrl_outb(1, RDAYCNT);
+		ctrl_outb(1, RMONCNT);
+#if defined(__SH4__)
+		ctrl_outw(0x2000, RYRCNT);
+#else
+		ctrl_outb(0, RYRCNT);
+#endif
+		ctrl_outb(RCR2_RTCEN|RCR2_START, RCR2);  /* Start */
+		goto again;
+	}
+
+	tv->tv_sec = mktime(yr100 * 100 + yr, mon, day, hr, min, sec);
+	tv->tv_usec = (sec128 * 1000000) / 128;
+}
+
+static int set_rtc_time(unsigned long nowtime)
+{
+	extern int abs (int);
+	int retval = 0;
+	int real_seconds, real_minutes, cmos_minutes;
+
+	ctrl_outb(RCR2_RESET, RCR2);  /* Reset pre-scaler & stop RTC */
+
+	cmos_minutes = ctrl_inb(RMINCNT);
+	BCD_TO_BIN(cmos_minutes);
+
+	/*
+	 * since we're only adjusting minutes and seconds,
+	 * don't interfere with hour overflow. This avoids
+	 * messing with unknown time zones but requires your
+	 * RTC not to be off by more than 15 minutes
+	 */
+	real_seconds = nowtime % 60;
+	real_minutes = nowtime / 60;
+	if (((abs(real_minutes - cmos_minutes) + 15)/30) & 1)
+		real_minutes += 30;	/* correct for half hour time zone */
+	real_minutes %= 60;
+
+	if (abs(real_minutes - cmos_minutes) < 30) {
+		BIN_TO_BCD(real_seconds);
+		BIN_TO_BCD(real_minutes);
+		ctrl_outb(real_seconds, RSECCNT);
+		ctrl_outb(real_minutes, RMINCNT);
+	} else {
+		printk(KERN_WARNING
+		       "set_rtc_time: can't update from %d to %d\n",
+		       cmos_minutes, real_minutes);
+		retval = -1;
+	}
+
+	ctrl_outb(RCR2_RTCEN|RCR2_START, RCR2);  /* Start RTC */
+
+	return retval;
+}
+
+int sh_rtc_settimeofday(const struct timeval *tv)
+{
+	return set_rtc_time(tv->tv_sec);
+}
+
+
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/time.c linux-aero/arch/sh/kernel/time.c
--- linuxsh/kernel/arch/sh/kernel/time.c	Mon Dec 11 06:12:13 2000
+++ linux-aero/arch/sh/kernel/time.c	Mon Dec 11 06:07:20 2000
@@ -28,6 +28,7 @@
 #include <asm/irq.h>
 #include <asm/delay.h>
 #include <asm/machvec.h>
+#include <asm/rtc.h>
 
 #include <linux/timex.h>
 #include <linux/irq.h>
@@ -38,20 +39,6 @@
 
 #define TMU0_TCR_CALIB	0x0000
 
-/* RCR1 Bits */
-#define RCR1_CF		0x80	/* Carry Flag             */
-#define RCR1_CIE	0x10	/* Carry Interrupt Enable */
-#define RCR1_AIE	0x08	/* Alarm Interrupt Enable */
-#define RCR1_AF		0x01	/* Alarm Flag             */
-
-/* RCR2 Bits */
-#define RCR2_PEF	0x80	/* PEriodic interrupt Flag */
-#define RCR2_PESMASK	0x70	/* Periodic interrupt Set  */
-#define RCR2_RTCEN	0x08	/* ENable RTC              */
-#define RCR2_ADJ	0x04	/* ADJustment (30-second)  */
-#define RCR2_RESET	0x02	/* Reset bit               */
-#define RCR2_START	0x01	/* Start bit               */
-
 #if defined(__sh3__)
 #define TMU_TOCR	0xfffffe90	/* Byte access */
 #define TMU_TSTR	0xfffffe92	/* Byte access */
@@ -61,25 +48,6 @@
 #define TMU0_TCR	0xfffffe9c	/* Word access */
 
 #define FRQCR		0xffffff80
-
-/* SH-3 RTC */
-#define R64CNT  	0xfffffec0
-#define RSECCNT 	0xfffffec2
-#define RMINCNT 	0xfffffec4
-#define RHRCNT  	0xfffffec6
-#define RWKCNT  	0xfffffec8
-#define RDAYCNT 	0xfffffeca
-#define RMONCNT 	0xfffffecc
-#define RYRCNT  	0xfffffece
-#define RSECAR  	0xfffffed0
-#define RMINAR  	0xfffffed2
-#define RHRAR   	0xfffffed4
-#define RWKAR   	0xfffffed6
-#define RDAYAR  	0xfffffed8
-#define RMONAR  	0xfffffeda
-#define RCR1    	0xfffffedc
-#define RCR2    	0xfffffede
-
 #elif defined(__SH4__)
 #define TMU_TOCR	0xffd80000	/* Byte access */
 #define TMU_TSTR	0xffd80004	/* Byte access */
@@ -89,32 +57,6 @@
 #define TMU0_TCR	0xffd80010	/* Word access */
 
 #define FRQCR		0xffc00000
-
-/* SH-4 RTC */
-#define R64CNT  	0xffc80000
-#define RSECCNT 	0xffc80004
-#define RMINCNT 	0xffc80008
-#define RHRCNT  	0xffc8000c
-#define RWKCNT  	0xffc80010
-#define RDAYCNT 	0xffc80014
-#define RMONCNT 	0xffc80018
-#define RYRCNT  	0xffc8001c  /* 16bit */
-#define RSECAR  	0xffc80020
-#define RMINAR  	0xffc80024
-#define RHRAR   	0xffc80028
-#define RWKAR   	0xffc8002c
-#define RDAYAR  	0xffc80030
-#define RMONAR  	0xffc80034
-#define RCR1    	0xffc80038
-#define RCR2    	0xffc8003c
-#endif
-
-#ifndef BCD_TO_BIN
-#define BCD_TO_BIN(val) ((val)=((val)&15) + ((val)>>4)*10)
-#endif
-
-#ifndef BIN_TO_BCD
-#define BIN_TO_BCD(val) ((val)=(((val)/10)<<4) + (val)%10)
 #endif
 
 extern rwlock_t xtime_lock;
@@ -220,46 +162,6 @@
 	write_unlock_irq(&xtime_lock);
 }
 
-static int set_rtc_time(unsigned long nowtime)
-{
-	extern int abs (int);
-	int retval = 0;
-	int real_seconds, real_minutes, cmos_minutes;
-
-	ctrl_outb(RCR2_RESET, RCR2);  /* Reset pre-scaler & stop RTC */
-
-	cmos_minutes = ctrl_inb(RMINCNT);
-	BCD_TO_BIN(cmos_minutes);
-
-	/*
-	 * since we're only adjusting minutes and seconds,
-	 * don't interfere with hour overflow. This avoids
-	 * messing with unknown time zones but requires your
-	 * RTC not to be off by more than 15 minutes
-	 */
-	real_seconds = nowtime % 60;
-	real_minutes = nowtime / 60;
-	if (((abs(real_minutes - cmos_minutes) + 15)/30) & 1)
-		real_minutes += 30;	/* correct for half hour time zone */
-	real_minutes %= 60;
-
-	if (abs(real_minutes - cmos_minutes) < 30) {
-		BIN_TO_BCD(real_seconds);
-		BIN_TO_BCD(real_minutes);
-		ctrl_outb(real_seconds, RSECCNT);
-		ctrl_outb(real_minutes, RMINCNT);
-	} else {
-		printk(KERN_WARNING
-		       "set_rtc_time: can't update from %d to %d\n",
-		       cmos_minutes, real_minutes);
-		retval = -1;
-	}
-
-	ctrl_outb(RCR2_RTCEN|RCR2_START, RCR2);  /* Start RTC */
-
-	return retval;
-}
-
 /* last time the RTC clock got updated */
 static long last_rtc_update;
 
@@ -289,7 +191,7 @@
 	    xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec >= 500000 - ((unsigned) tick) / 2 &&
 	    xtime.tv_usec <= 500000 + ((unsigned) tick) / 2) {
-		if (set_rtc_time(xtime.tv_sec) == 0)
+		if (sh_mv.mv_rtc_settimeofday(&xtime) == 0)
 			last_rtc_update = xtime.tv_sec;
 		else
 			last_rtc_update = xtime.tv_sec - 600; /* do it again in 60 s */
@@ -322,64 +224,12 @@
 	write_unlock(&xtime_lock);
 }
 
-static unsigned long get_rtc_time(void)
-{
-	unsigned int sec, min, hr, wk, day, mon, yr, yr100;
-
- again:
-	do {
-		ctrl_outb(0, RCR1);  /* Clear CF-bit */
-		sec = ctrl_inb(RSECCNT);
-		min = ctrl_inb(RMINCNT);
-		hr  = ctrl_inb(RHRCNT);
-		wk  = ctrl_inb(RWKCNT);
-		day = ctrl_inb(RDAYCNT);
-		mon = ctrl_inb(RMONCNT);
-#if defined(__SH4__)
-		yr  = ctrl_inw(RYRCNT);
-		yr100 = (yr >> 8);
-		yr &= 0xff;
-#else
-		yr  = ctrl_inb(RYRCNT);
-		yr100 = (yr == 0x99) ? 0x19 : 0x20;
-#endif
-	} while ((ctrl_inb(RCR1) & RCR1_CF) != 0);
-
-	BCD_TO_BIN(yr100);
-	BCD_TO_BIN(yr);
-	BCD_TO_BIN(mon);
-	BCD_TO_BIN(day);
-	BCD_TO_BIN(hr);
-	BCD_TO_BIN(min);
-	BCD_TO_BIN(sec);
-
-	if (yr > 99 || mon < 1 || mon > 12 || day > 31 || day < 1 ||
-	    hr > 23 || min > 59 || sec > 59) {
-		printk(KERN_ERR
-		       "SH RTC: invalid value, resetting to 1 Jan 2000\n");
-		ctrl_outb(RCR2_RESET, RCR2);  /* Reset & Stop */
-		ctrl_outb(0, RSECCNT);
-		ctrl_outb(0, RMINCNT);
-		ctrl_outb(0, RHRCNT);
-		ctrl_outb(6, RWKCNT);
-		ctrl_outb(1, RDAYCNT);
-		ctrl_outb(1, RMONCNT);
-#if defined(__SH4__)
-		ctrl_outw(0x2000, RYRCNT);
-#else
-		ctrl_outb(0, RYRCNT);
-#endif
-		ctrl_outb(RCR2_RTCEN|RCR2_START, RCR2);  /* Start */
-		goto again;
-	}
-
-	return mktime(yr100 * 100 + yr, mon, day, hr, min, sec);
-}
-
 static unsigned int __init get_timer_frequency(void)
 {
 	u32 freq;
-	u8 r64cnt;
+	struct timeval tv1, tv2;
+	unsigned long diff_usec;
+	unsigned long factor;
 
 	/* Setup the timer:  We don't want to generate interrupts, just
 	 * have it count down at its natural rate.
@@ -390,22 +240,37 @@
 	ctrl_outl(0xffffffff, TMU0_TCOR);
 	ctrl_outl(0xffffffff, TMU0_TCNT);
 
-	/* wait until the current 1/128th second is over */
-	r64cnt = ctrl_inb(R64CNT);
-	while (ctrl_inb(R64CNT) == r64cnt);
-	
+	rtc_gettimeofday(&tv2);
+
+	do {
+		rtc_gettimeofday(&tv1);
+	} while (tv1.tv_usec == tv2.tv_usec && tv1.tv_sec == tv2.tv_sec);
+
 	/* actually start the timer */
 	ctrl_outb(TMU_TSTR_INIT, TMU_TSTR);
 
-	/* wait 1/128th of a second */
-	r64cnt = ctrl_inb(R64CNT);
-	while (ctrl_inb(R64CNT) == r64cnt);
-	
+	do {
+		rtc_gettimeofday(&tv2);
+	} while (tv1.tv_usec == tv2.tv_usec && tv1.tv_sec == tv2.tv_sec);
+
 	freq = 0xffffffff - ctrl_inl(TMU0_TCNT);
-	
-	freq *= 128;
+	if (tv2.tv_usec < tv1.tv_usec) {
+		tv2.tv_usec += 1000000;
+		tv2.tv_sec--;
+	}
+
+	diff_usec = (tv2.tv_sec - tv1.tv_sec) * 1000000 + (tv2.tv_usec - tv1.tv_usec);
+
+	/* this should work well if the RTC has a precision of n Hz, where
+	 * n is an integer.  I don't think we have to worry about the other
+	 * cases. */
+	factor = (1000000 + diff_usec/2) / diff_usec;
+
+	if (factor * diff_usec > 1100000 ||
+	    factor * diff_usec <  900000)
+		panic("weird RTC (diff_usec %ld)", diff_usec);
 
-	return freq;
+	return freq * factor;
 }
 
 static struct irqaction irq0  = { timer_interrupt, SA_INTERRUPT, 0, "timer", NULL, NULL};
@@ -426,8 +291,7 @@
 	static int pfc_table[] = { 2, 3, 4, 6, 8, 2, 2, 2 };
 #endif
 
-	xtime.tv_sec = get_rtc_time();
-	xtime.tv_usec = 0;
+	rtc_gettimeofday(&xtime);
 
 	setup_irq(TIMER_IRQ, &irq0);
 
diff -urNx CVS linuxsh/kernel/include/asm-sh/machvec.h linux-aero/include/asm-sh/machvec.h
--- linuxsh/kernel/include/asm-sh/machvec.h	Fri Dec  8 13:32:58 2000
+++ linux-aero/include/asm-sh/machvec.h	Mon Dec 11 04:59:49 2000
@@ -13,6 +13,8 @@
 #include <linux/config.h>
 #include <linux/types.h>
 
+struct timeval;
+
 struct sh_machine_vector
 {
 	const char *mv_name;
@@ -61,6 +63,9 @@
 
 	void (*mv_heartbeat)(void);
 
+	void (*mv_rtc_gettimeofday)(struct timeval *tv);
+	int (*mv_rtc_settimeofday)(const struct timeval *tv);
+
 	unsigned int mv_hw_se : 1;
 	unsigned int mv_hw_hp600 : 1;
 	unsigned int mv_hw_hp620 : 1;
diff -urNx CVS linuxsh/kernel/include/asm-sh/rtc.h linux-aero/include/asm-sh/rtc.h
--- linuxsh/kernel/include/asm-sh/rtc.h	Wed Dec 31 16:00:00 1969
+++ linux-aero/include/asm-sh/rtc.h	Mon Dec 11 05:05:33 2000
@@ -0,0 +1,12 @@
+#ifndef _ASM_RTC_H
+#define _ASM_RTC_H
+
+#include <asm/machvec.h>
+
+#define rtc_gettimeofday sh_mv.mv_rtc_gettimeofday
+#define rtc_settimeofday sh_mv.mv_rtc_settimeofday
+
+extern void sh_rtc_gettimeofday(struct timeval *tv);
+extern int sh_rtc_settimeofday(const struct timeval *tv);
+
+#endif /* _ASM_RTC_H */

[linuxsh-dev] Re: New toolchain

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

Hi,

Denis Dowling <dp...@pr...> wrote:
> I am having some problems building the new toolchain.
[snip]
> 4) Finally I am having problems getting the new ld.so.1 and glibc.so.6
> working on my target. I just get segmentation faults when I install
> ld.so.1. I noticed that the ABI has changed. Does this mean that I also
> need different kernel support. It could also be that I have missed a patch.
> I am currently using a patched version of glibc-2.1.3. Would going to
> glibc2.2 help?

New toolchain needs the dynamic linker in glibc-2.2.

	kaz

[linuxsh-dev] New toolchain

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

Denis Dowling wrote:
 > 1) What are the configuration options for gcc to prevent it trying to
 > build zlib. Currently
 >    I configure gcc as per Stuart Menefy's notes and it attempts to build
 > zlib and bombs. I
 >    can work around this by changing into the gcc subdirectory and doing
 > a make install here
 >    but there must be a better way.

make cross-gcc
Don't let it make run-time library.

 > 2) The new cpplib in gcc looks to have some bugs. This causes it to
 > produce strange output
 >    into the kernel/arch/sh/ld.script. I have worked around this with an
 > awk script.

Please use -traditional
-- 

[linuxsh-dev] New toolchain

[Denis D. <dp...@pr...>]

I am having some problems building the new toolchain.

Specifically I am building:
binutils-001005.tar.gz with patch binutils-001005.diff.gz
egcs-core-20001002.tar.gz with patch gcc-200010002.diff.gz
glibc-2.1.3.tar.bz2 

1) What are the configuration options for gcc to prevent it trying to
build zlib. Currently
   I configure gcc as per Stuart Menefy's notes and it attempts to build
zlib and bombs. I
   can work around this by changing into the gcc subdirectory and doing
a make install here
   but there must be a better way.

2) The new cpplib in gcc looks to have some bugs. This causes it to
produce strange output
   into the kernel/arch/sh/ld.script. I have worked around this with an
awk script.

3) gcc now exits with an error when compiling an empty file. Parts of
glibc do this.
   Again the work around is straight forward.

4) Finally I am having problems getting the new ld.so.1 and glibc.so.6
working on my
   target. I just get segmentation faults when I install ld.so.1. I
noticed that the ABI
   has changed. Does this mean that I also need different kernel
support. It could
   also be that I have missed a patch. I am currently using a patched
version of
   glibc-2.1.3. Would going to glibc2.2 help?

Thanks in advance for the help

Regards,
Denis Dowling

Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Sun, Dec 10, 2000 at 07:28:35PM -0600, M. R. Brown wrote:
> Manual also has the table (or check time.c).  The clever (it is clever,
> even though it doesn't work for the DC :) get_timer_frequency code checks

Okay, here's another proposal that should preserve the good attributes of
this code:

let's use struct timeval *s for the RTC routines.  Thus, we have

void rtc_gettimeofday(struct timeval *);
int rtc_settimeofday(const struct timeval *);

and get_timer_frequency looks like this (untested):

static unsigned int __init get_timer_frequency(void)
{
	u32 freq;
	struct timeval tv1, tv2;
	unsigned long diff_usec;

	/* Setup the timer:  We don't want to generate interrupts, just
	 * have it count down at its natural rate.
	 */
	ctrl_outb(0, TMU_TSTR);
	ctrl_outb(TMU_TOCR_INIT, TMU_TOCR);
	ctrl_outw(TMU0_TCR_CALIB, TMU0_TCR);
	ctrl_outl(0xffffffff, TMU0_TCOR);
	ctrl_outl(0xffffffff, TMU0_TCNT);

	rtc_gettimeofday(&tv2);

	do {
		rtc_gettimeofday(&tv1);
	} while (tv1.usec == tv2.usec && tv1.sec == tv2.sec);

	/* actually start the timer */
	ctrl_outb(TMU_TSTR_INIT, TMU_TSTR);

wait:
	do {
		rtc_gettimeofday(&tv2);
	} while (tv1.usec == tv2.usec && tv1.sec == tv2.sec);

	freq = 0xffffffff - ctrl_inl(TMU0_TCNT);
	if (tv2.usec < tv1.usec) {
		tv2.usec += 1000000;
		tv2.sec--;
	}

	diff_usec = (tv2.sec - tv1.sec) * 1000000 + (tv2.usec - tv1.usec);

	/* wait at least one ms so our result will be roughly accurate */
	if (diff_usec < 1000)
		goto wait;

	/* this should work well if the RTC has a precision of n Hz, where
	 * n is an integer.  I don't think we have to worry about the other
	 * cases. */
	factor = (1000000 + diff_usec/2) / diff_usec;

	if (factor * diff_usec > 1100000 ||
	    factor * diff_usec <  900000)
		panic("weird RTC (diff_usec %ld)", diff_usec);

	return freq * factor;
}

This should give exactly the right results for both 1 Hz and 128 Hz RTCs,
and work for all but the weirdest RTCs out there.

Is this okay with everyone ?

Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Sat, 9 Dec 2000, Rene Malmgren wrote:

> Philipp Rumpf wrote:
> > 
> > On Thu, Dec 07, 2000 at 04:29:38PM +0100, Rene Malmgren wrote:
> > > Philipp Rumpf wrote:
> > > > > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > > > > me, but they're static as well (they're probably the standard SH4 ratio).
> > > > you can find those out by decoding FQCR.
> > > FQCR ?
> > 
> > FRQCR, sorry.
> 
> Mening?
> 
> Could you please explai the theory behind the initialisation of the bus
> freq. And how the values are calculated.
> I am personaly having trouble with hanings if I use a value above 20.000
> and as I understand it the value for the DC should be 200.000.000 (200
> Mhz)
> 

The meaning and specs of the FRQCR hardware register are taken right from
the SH7750 hardware manual.  Basically it tells you how fast the cpu clock
(ifc), bus clock (bfc), and peripheral/module clock (pfc) are running in
relation to the master clock (or, the crystal on the mainboard).  The HW
Manual also has the table (or check time.c).  The clever (it is clever,
even though it doesn't work for the DC :) get_timer_frequency code checks
the value of 1/128 of a second (using the interval timer R64CNT, also
broken on the DC) while counting down from TMU0.  This gives an accurate
value of the peripheral clock (pfc), which can be used to calculate the
master clock, bus clock, and cpu clock.  If we can find another way to
activate an interval timer on the DC (currently I'm suspicious of the
AICA, I think there's one in there somewhere), then we can use the same
code, just with our interval timer, but that could potentially get messy
(i.e. another call _within_ get_timer_frequency!).

> > 
> > > The get_timer_freq functions is modified to fit the new RTC interface.
> > >
> > > This way embedded systems can use a predefined value, and hence boot
> > > fast. And lazy people can use the auto detect and pay the 1,5 sec
> > > penalty. As an bonus we get nice modular code and move one step away
> > > from the abyss.
> > >
> > > I dont think its a good coding practise to go pass the RTC interface and
> > > go directly at the hardware.
> > 
> > We don't rely on the hardware we access being an RTC at all - all we need
> > is to know the rate of change of the hardware register we read (the
> > equivalent code on x86 uses the PIT).  Using the RTC interface if you're
> > not using RTC functionality doesn't sound like a good idea.
> 
> Ok you arn't using the RTC as an RTC but you are using it as a CLOCK.
> Whitch dosn't work on all platforms, well atleast not on the DC. But you
> are right we could hardcode in the value for the DC. And make the
> problem go awy. Or we could extend the RTC interface to  make i that of
> a general clock. With diferent resulution for different RTC:s 
> 

The fact that the interval timer is on the builtin RTC has nothing to do
with using an interval timer, per se, it's just that the RTC is completely
disabled on the DC so we _need_ another interval timer for this to work.
But we seem to be going in circles here...?

> in other words adding the folowing
> unsigned int rtc_clockticks; 			// The number of ticks the RTC makes in
> an second
> 						// Thats 128 for a std SH RTC and 1 for a DC.
> void 	rtc_sleep(unsigned int count);		// functions that sleeps for cont
> ticks
> 
> > 
> > > I get a feeling that doing things like that
> > > is a good way to introduse hard found bugs.
> > 
> > And not doing things this way introduces limitations that I think would be
> > unacceptable to many people;  it would also, IMHO needlessly, move things
> > out of the cpu data structures into the machvec.
> 
> Sure you are right the time_freq don't belong in the machvec. But
> neither does the get_time_freq functions. I'll vote for the extended
> clock. Because either way we have to find a way for other parts of the
> kernel to understand the behavior of the clock.
> 

I'm not sure what you mean by extended clock.  I know the 386 Linux
target has "Enhanced RTC support" which allows you to play with interval
timers, is this what you're talking about?

Can we come to an agreement about cleaning this up?  Is it, "put RTC stuff
into the machvec so that machines can use it generically or custom"; and
"find an autocalibration routine for the DC" - or is it something else?

M. R.

Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Sat, 9 Dec 2000, Philipp Rumpf wrote:

> On Thu, Dec 07, 2000 at 04:29:38PM +0100, Rene Malmgren wrote:
> > Philipp Rumpf wrote:
> > > > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > > > me, but they're static as well (they're probably the standard SH4 ratio).
> > > you can find those out by decoding FQCR.
> > FQCR ?
> 
> FRQCR, sorry.
> 
> > > For DC it's probably not that much of an issue - for embedded systems it
> > > definitely is.
> 
> > Well yes. But the functions we are talking about are forms of auto
> > detect. Its my personal view that If you got an embedded system with
> 
> there's no way to find out whether your fixed value is correct unless you
> calibrated it (other than comparing with an external time source).  As on
> most SH systems the calibration takes less than 20 ms I don't think it's
> a good idea to ever use a constant timer value for those - for the DC it's
> a different issue.
> 

In order to get my DC to boot I've been using a constant (using #if 0
fare) value of timer_freq = 12500000 (I may be off a zero, I don't have
the source handy).  I can verify this works because the serial console
works at 57600, and it uses the peripheral clock to set the baud rate.
While that doesn't qualify as an external source (heh :), I have an idea
how we can work around the DC's broken interval timer (R64CNT).  Read on.

> > 2 Add an constant to the macvector representing the timer_frequency.
> > 
> > mv_time_freq
> > 
> > This variable is either set by a constant or for the generic vector, by
> > auto detect.
> 
> or specifid on the command line (since 2 seconds of delay during boot just
> because you don't know your CPU speed just aren't acceptable) ?
> 

It's a waste of effort to create a command line parameter for the
frequency if it can be autodetected.  I believe it can be even on the DC,
using timers on the AICA RTC.

> > The get_timer_freq functions is modified to fit the new RTC interface.
> > 
> > This way embedded systems can use a predefined value, and hence boot
> > fast. And lazy people can use the auto detect and pay the 1,5 sec
> > penalty. As an bonus we get nice modular code and move one step away
> > from the abyss.
> > 
> > I dont think its a good coding practise to go pass the RTC interface and
> > go directly at the hardware.
> 
> We don't rely on the hardware we access being an RTC at all - all we need
> is to know the rate of change of the hardware register we read (the
> equivalent code on x86 uses the PIT).  Using the RTC interface if you're
> not using RTC functionality doesn't sound like a good idea.
> 

Ok, here we go.  The AICA sound system (where the DC's RTC is located) has
interval timers (based on the code I've seen to drive the sound
processor).  The only problem is, it may be a kludge to activate the timer
depending on how it's activated.  The AICA system can be accessed from two
places, from the SH-4 or the ARM core that powers the AICA.  I don't know
yet if the IT can be activated from the SH-4 side, if so, we're in luck. 
If not, I'm willing to throw in the towel and special case the timer_freq
value for the Dreamcast to a constant value.  But the elegant, DC-portable
solution would be to try to get the AICA IT working, but I have to spend
some time playing with it to see *exactly* how it works.  If anyone
(Marcus, please? :) has info on AICA timers and if they can be used as an
IT from the SH-4 side please let me know.

> > I get a feeling that doing things like that
> > is a good way to introduse hard found bugs.
> 
> And not doing things this way introduces limitations that I think would be
> unacceptable to many people;  it would also, IMHO needlessly, move things
> out of the cpu data structures into the machvec.
>

I agree here.  get_ and set_rtc_time should go into the machvec, but timer
calibration is another beast altogether.  Now that I understand what's
going on, I would hate to kludge up the timer_freq with a constant value,
so I will try an exhaust other possibilities for auto-calibration on the
DC.  In the end, unless time.c is split off it will boil down to a #ifdef
CONFIG_SH_DREAMCAST to distinguish between the two (since there seems to
be no other SH4-based hardware with no onboard RTC).

M. R.

Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <re...@dr...>]

Philipp Rumpf wrote:
> 
> On Thu, Dec 07, 2000 at 04:29:38PM +0100, Rene Malmgren wrote:
> > Philipp Rumpf wrote:
> > > > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > > > me, but they're static as well (they're probably the standard SH4 ratio).
> > > you can find those out by decoding FQCR.
> > FQCR ?
> 
> FRQCR, sorry.

Mening?

Could you please explai the theory behind the initialisation of the bus
freq. And how the values are calculated.
I am personaly having trouble with hanings if I use a value above 20.000
and as I understand it the value for the DC should be 200.000.000 (200
Mhz)

> 
> > > For DC it's probably not that much of an issue - for embedded systems it
> > > definitely is.
> 
> > Well yes. But the functions we are talking about are forms of auto
> > detect. Its my personal view that If you got an embedded system with
> 
> there's no way to find out whether your fixed value is correct unless you
> calibrated it (other than comparing with an external time source).  As on
> most SH systems the calibration takes less than 20 ms I don't think it's
> a good idea to ever use a constant timer value for those - for the DC it's
> a different issue.

Ok. 

> 
> > 2 Add an constant to the macvector representing the timer_frequency.
> >
> > mv_time_freq
> >
> > This variable is either set by a constant or for the generic vector, by
> > auto detect.
> 
> or specifid on the command line (since 2 seconds of delay during boot just
> because you don't know your CPU speed just aren't acceptable) ?

Ok.

> 
> > The get_timer_freq functions is modified to fit the new RTC interface.
> >
> > This way embedded systems can use a predefined value, and hence boot
> > fast. And lazy people can use the auto detect and pay the 1,5 sec
> > penalty. As an bonus we get nice modular code and move one step away
> > from the abyss.
> >
> > I dont think its a good coding practise to go pass the RTC interface and
> > go directly at the hardware.
> 
> We don't rely on the hardware we access being an RTC at all - all we need
> is to know the rate of change of the hardware register we read (the
> equivalent code on x86 uses the PIT).  Using the RTC interface if you're
> not using RTC functionality doesn't sound like a good idea.

Ok you arn't using the RTC as an RTC but you are using it as a CLOCK.
Whitch dosn't work on all platforms, well atleast not on the DC. But you
are right we could hardcode in the value for the DC. And make the
problem go awy. Or we could extend the RTC interface to  make i that of
a general clock. With diferent resulution for different RTC:s 

in other words adding the folowing
unsigned int rtc_clockticks; 			// The number of ticks the RTC makes in
an second
						// Thats 128 for a std SH RTC and 1 for a DC.
void 	rtc_sleep(unsigned int count);		// functions that sleeps for cont
ticks

> 
> > I get a feeling that doing things like that
> > is a good way to introduse hard found bugs.
> 
> And not doing things this way introduces limitations that I think would be
> unacceptable to many people;  it would also, IMHO needlessly, move things
> out of the cpu data structures into the machvec.

Sure you are right the time_freq don't belong in the machvec. But
neither does the get_time_freq functions. I'll vote for the extended
clock. Because either way we have to find a way for other parts of the
kernel to understand the behavior of the clock.

/Rene

Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Thu, Dec 07, 2000 at 04:29:38PM +0100, Rene Malmgren wrote:
> Philipp Rumpf wrote:
> > > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > > me, but they're static as well (they're probably the standard SH4 ratio).
> > you can find those out by decoding FQCR.
> FQCR ?

FRQCR, sorry.

> > For DC it's probably not that much of an issue - for embedded systems it
> > definitely is.

> Well yes. But the functions we are talking about are forms of auto
> detect. Its my personal view that If you got an embedded system with

there's no way to find out whether your fixed value is correct unless you
calibrated it (other than comparing with an external time source).  As on
most SH systems the calibration takes less than 20 ms I don't think it's
a good idea to ever use a constant timer value for those - for the DC it's
a different issue.

> 2 Add an constant to the macvector representing the timer_frequency.
> 
> mv_time_freq
> 
> This variable is either set by a constant or for the generic vector, by
> auto detect.

or specifid on the command line (since 2 seconds of delay during boot just
because you don't know your CPU speed just aren't acceptable) ?

> The get_timer_freq functions is modified to fit the new RTC interface.
> 
> This way embedded systems can use a predefined value, and hence boot
> fast. And lazy people can use the auto detect and pay the 1,5 sec
> penalty. As an bonus we get nice modular code and move one step away
> from the abyss.
> 
> I dont think its a good coding practise to go pass the RTC interface and
> go directly at the hardware.

We don't rely on the hardware we access being an RTC at all - all we need
is to know the rate of change of the hardware register we read (the
equivalent code on x86 uses the PIT).  Using the RTC interface if you're
not using RTC functionality doesn't sound like a good idea.

> I get a feeling that doing things like that
> is a good way to introduse hard found bugs.

And not doing things this way introduces limitations that I think would be
unacceptable to many people;  it would also, IMHO needlessly, move things
out of the cpu data structures into the machvec.

	Philipp Rumpf

[linuxsh-dev] [PATCH] Basic EC3104 Support

[Philipp R. <pr...@pa...>]

Hello,
this patch adds support for some of the basic functionality of the EC3104
companion chip, which is used in the Compaq Aero 8000 wince laptop series
(at least some of them, that is).  This includes interrupt support,
support for byte IO operations on the ISA bus, and support for the serial
ports (using the generic driver).

2000-12-09  Philipp Rumpf <pr...@tu...>
	* arch/sh/kernel/mach_ec3104.c, arch/sh/kernel/io_ec3104.c,
	arch/sh/kernel/setup_ec3104.c, include/asm-sh/ec3104.h,
	include/asm-sh/io_ec3104.h, include/asm-sh/serial-ec3104.h: New files

	* arch/sh/config.in, arch/sh/kernel/Makefile, include/asm-sh/io.h,
	include/asm-sh/irq.h, include/asm-sh/machvec.h: Added support for
	the EC3104 companion chip.

	* include/asm-sh/serial.h [CONFIG_SH_EC3104]: Use alternate header
	file for EC3104.

If anyone's interested, I'm running Linux on the Aero 8000 quite nicely,
but some of the drivers are currently being cleaned up.  In particular, I
expect to release the following things shortly:
 - support for the aero 8000 keyboard controller
 - support for the ec3104 ps2 port (aero 8000 touch pad)
 - support for the epson 1355 lcd/crt controller
 - a boot loader

	Philipp Rumpf


diff -urNx CVS linuxsh/kernel/arch/sh/config.in linux-aero/arch/sh/config.in
--- linuxsh/kernel/arch/sh/config.in	Fri Dec  8 13:30:10 2000
+++ linux-aero/arch/sh/config.in	Fri Dec  8 13:11:46 2000
@@ -33,6 +33,7 @@
 	 HP690			CONFIG_SH_HP690			\
 	 CqREEK			CONFIG_SH_CQREEK		\
 	 FOOBAR			CONFIG_SH_FOOBAR    		\
+	 EC3104			CONFIG_SH_EC3104		\
 	 BareCPU		CONFIG_SH_UNKNOWN" Generic
 
 if [ "$CONFIG_SH_HP620" = "y" -o "$CONFIG_SH_HP680" = "y" -o \
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/Makefile linux-aero/arch/sh/kernel/Makefile
--- linuxsh/kernel/arch/sh/kernel/Makefile	Fri Dec  8 13:30:11 2000
+++ linux-aero/arch/sh/kernel/Makefile	Fri Dec  8 13:38:29 2000
@@ -61,6 +61,10 @@
 O_OBJS += setup_hd64465.o io_hd64465.o hd64465_gpio.o
 endif
 
+ifneq ($(CONFIG_SH_EC3104),)
+O_OBJS += mach_ec3104.o setup_ec3104.o io_ec3104.o io_generic.o
+endif
+
 ifdef CONFIG_SH_STANDARD_BIOS
 O_OBJS += sh_bios.o
 endif
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/io_ec3104.c linux-aero/arch/sh/kernel/io_ec3104.c
--- linuxsh/kernel/arch/sh/kernel/io_ec3104.c	Wed Dec 31 16:00:00 1969
+++ linux-aero/arch/sh/kernel/io_ec3104.c	Fri Dec  8 14:30:24 2000
@@ -0,0 +1,83 @@
+/*
+ * linux/arch/sh/kernel/io_ec3104.c
+ *  EC3104 companion chip support
+ *
+ * Copyright (C) 2000 Philipp Rumpf <pr...@tu...>
+ *
+ */
+/* EC3104 note:
+ * This code was written without any documentation about the EC3104 chip.  While
+ * I hope I got most of the basic functionality right, the register names I use
+ * are most likely completely different from those in the chip documentation.
+ *
+ * If you have any further information about the EC3104, please tell me
+ * (pr...@tu...).
+ */
+
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <asm/io.h>
+#include <asm/page.h>
+#include <asm/ec3104.h>
+
+/*
+ * EC3104 has a real ISA bus which we redirect low port accesses to (the
+ * actual device on mine is a ESS 1868, and I don't want to hack the driver
+ * more than strictly necessary).  I am not going to duplicate the
+ * hard coding of PC addresses (for the 16550s aso) here though;  it's just
+ * too ugly.
+ */
+
+#define low_port(port) ((port) < 0x10000)
+
+static inline unsigned long port2addr(unsigned long port)
+{
+	switch(port >> 16) {
+	case 0:
+		return EC3104_ISA_BASE + port * 2;
+
+		/* XXX hack. it's unclear what to do about the serial ports */
+	case 1:
+		return EC3104_BASE + (port&0xffff) * 4;
+
+	default:
+		/* XXX PCMCIA */
+		return 0;
+	}
+}
+
+unsigned char ec3104_inb(unsigned long port)
+{
+	u8 ret;
+
+	ret = *(volatile u8 *)port2addr(port);
+
+	return ret;
+}
+
+unsigned short ec3104_inw(unsigned long port)
+{
+	BUG();
+}
+
+unsigned long ec3104_inl(unsigned long port)
+{
+	BUG();
+}
+
+void ec3104_outb(unsigned char data, unsigned long port)
+{
+	*(volatile u8 *)port2addr(port) = data;
+}
+
+void ec3104_outw(unsigned short data, unsigned long port)
+{
+	BUG();
+}
+
+void ec3104_outl(unsigned long data, unsigned long port)
+{
+	BUG();
+}
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/mach_ec3104.c linux-aero/arch/sh/kernel/mach_ec3104.c
--- linuxsh/kernel/arch/sh/kernel/mach_ec3104.c	Wed Dec 31 16:00:00 1969
+++ linux-aero/arch/sh/kernel/mach_ec3104.c	Fri Dec  8 14:30:18 2000
@@ -0,0 +1,66 @@
+/*
+ * linux/arch/sh/kernel/mach_ec3104.c
+ *  EC3104 companion chip support
+ *
+ * Copyright (C) 2000 Philipp Rumpf <pr...@tu...>
+ *
+ */
+/* EC3104 note:
+ * This code was written without any documentation about the EC3104 chip.  While
+ * I hope I got most of the basic functionality right, the register names I use
+ * are most likely completely different from those in the chip documentation.
+ *
+ * If you have any further information about the EC3104, please tell me
+ * (pr...@tu...).
+ */
+
+#include <linux/init.h>
+
+#include <asm/machvec.h>
+#include <asm/machvec_init.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+
+/*
+ * The Machine Vector
+ */
+
+struct sh_machine_vector mv_ec3104 __initmv = {
+	mv_name:		"EC3104",
+
+	mv_nr_irqs:		96,
+
+	mv_inb:			ec3104_inb,
+	mv_inw:			ec3104_inw,
+	mv_inl:			ec3104_inl,
+	mv_outb:		ec3104_outb,
+	mv_outw:		ec3104_outw,
+	mv_outl:		ec3104_outl,
+
+	mv_inb_p:		generic_inb_p,
+	mv_inw_p:		generic_inw,
+	mv_inl_p:		generic_inl,
+	mv_outb_p:		generic_outb_p,
+	mv_outw_p:		generic_outw,
+	mv_outl_p:		generic_outl,
+
+	mv_insb:		generic_insb,
+	mv_insw:		generic_insw,
+	mv_insl:		generic_insl,
+	mv_outsb:		generic_outsb,
+	mv_outsw:		generic_outsw,
+	mv_outsl:		generic_outsl,
+
+	mv_readb:		generic_readb,
+	mv_readw:		generic_readw,
+	mv_readl:		generic_readl,
+	mv_writeb:		generic_writeb,
+	mv_writew:		generic_writew,
+	mv_writel:		generic_writel,
+
+	mv_irq_demux:		ec3104_irq_demux,
+
+};
+
+ALIAS_MV(ec3104)
diff -urNx CVS linuxsh/kernel/arch/sh/kernel/setup_ec3104.c linux-aero/arch/sh/kernel/setup_ec3104.c
--- linuxsh/kernel/arch/sh/kernel/setup_ec3104.c	Wed Dec 31 16:00:00 1969
+++ linux-aero/arch/sh/kernel/setup_ec3104.c	Fri Dec  8 14:29:51 2000
@@ -0,0 +1,165 @@
+/*
+ * linux/arch/sh/kernel/setup_ec3104.c
+ *  EC3104 companion chip support
+ *
+ * Copyright (C) 2000 Philipp Rumpf <pr...@tu...>
+ *
+ */
+/* EC3104 note:
+ * This code was written without any documentation about the EC3104 chip.  While
+ * I hope I got most of the basic functionality right, the register names I use
+ * are most likely completely different from those in the chip documentation.
+ *
+ * If you have any further information about the EC3104, please tell me
+ * (pr...@tu...).
+ */
+
+#include <linux/config.h>
+#include <linux/sched.h>
+#include <linux/kernel.h>
+#include <linux/param.h>
+#include <linux/interrupt.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/types.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/ec3104.h>
+
+/* I used the register names from another interrupt controller I worked with,
+ * since it seems to be identical to the ec3104 except that all bits are
+ * inverted:
+ *
+ * IRR: Interrupt Request Register (pending and enabled interrupts)
+ * IMR: Interrupt Mask Register (which interrupts are enabled)
+ * IPR: Interrupt Pending Register (pending interrupts, even disabled ones)
+ *
+ * 0 bits mean pending or enabled, 1 bits mean not pending or disabled.  all
+ * IRQs seem to be level-triggered.
+ */
+
+#define EC3104_IRR (EC3104_BASE + 0x1000)
+#define EC3104_IMR (EC3104_BASE + 0x1004)
+#define EC3104_IPR (EC3104_BASE + 0x1008)
+
+#define ctrl_readl(addr) (*(volatile u32 *)(addr))
+#define ctrl_writel(data,addr) (*(volatile u32 *)(addr) = (data))
+#define ctrl_readb(addr) (*(volatile u8 *)(addr))
+
+static inline u32 ec3104_irq2mask(unsigned int irq)
+{
+	return (1 << (irq - EC3104_IRQBASE));
+}
+
+static inline void mask_ec3104_irq(unsigned int irq)
+{
+	u32 mask;
+
+	mask = ctrl_readl(EC3104_IMR);
+
+	mask |= ec3104_irq2mask(irq);
+	
+	ctrl_writel(mask, EC3104_IMR);
+}
+	
+static inline void unmask_ec3104_irq(unsigned int irq)
+{
+	u32 mask;
+
+	mask = ctrl_readl(EC3104_IMR);
+
+	mask &= ~ec3104_irq2mask(irq);
+	
+	ctrl_writel(mask, EC3104_IMR);
+}
+	
+static void disable_ec3104_irq(unsigned int irq)
+{
+	mask_ec3104_irq(irq);
+}
+
+static void enable_ec3104_irq(unsigned int irq)
+{
+	unmask_ec3104_irq(irq);
+}
+
+static void mask_and_ack_ec3104_irq(unsigned int irq)
+{
+	mask_ec3104_irq(irq);
+}
+
+static void end_ec3104_irq(unsigned int irq)
+{
+	unmask_ec3104_irq(irq);
+}
+
+static unsigned int startup_ec3104_irq(unsigned int irq)
+{
+	unmask_ec3104_irq(irq);
+
+	return 0;
+}
+
+static void shutdown_ec3104_irq(unsigned int irq)
+{
+	mask_ec3104_irq(irq);
+
+}
+
+static struct hw_interrupt_type ec3104_int = {
+	typename:	"EC3104",
+	enable:		enable_ec3104_irq,
+	disable:	disable_ec3104_irq,
+	ack:		mask_and_ack_ec3104_irq,
+	end:		end_ec3104_irq,
+	startup:	startup_ec3104_irq,
+	shutdown:	shutdown_ec3104_irq,
+};
+
+/* Yuck.  the _demux API is ugly */
+int ec3104_irq_demux(int irq)
+{
+	if (irq == EC3104_IRQ) {
+		unsigned int mask;
+
+		mask = ctrl_readl(EC3104_IRR);
+
+		if (mask == 0xffffffff)
+			return EC3104_IRQ;
+		else
+			return EC3104_IRQBASE + ffz(mask);
+	}
+
+	return irq;
+}
+
+int __init setup_ec3104(void)
+{
+	char str[8];
+	int i;
+	
+	if (!MACH_EC3104)
+		printk("!MACH_EC3104\n");
+
+	if (0)
+		return 0;
+
+	for (i=0; i<8; i++)
+		str[i] = ctrl_readb(EC3104_BASE + i);
+
+	for (i = EC3104_IRQBASE; i < EC3104_IRQBASE + 32; i++)
+		irq_desc[i].handler = &ec3104_int;
+
+	printk("initializing EC3104 \"%.8s\" at %08x, IRQ %d, IRQ base %d\n",
+	       str, EC3104_BASE, EC3104_IRQ, EC3104_IRQBASE);
+
+
+	/* mask all interrupts.  this should have been done by the boot
+	 * loader for us but we want to be sure ... */
+	ctrl_writel(0xffffffff, EC3104_IMR);
+	
+	return 0;
+}
+
+module_init(setup_ec3104);
diff -urNx CVS linuxsh/kernel/include/asm-sh/ec3104.h linux-aero/include/asm-sh/ec3104.h
--- linuxsh/kernel/include/asm-sh/ec3104.h	Wed Dec 31 16:00:00 1969
+++ linux-aero/include/asm-sh/ec3104.h	Fri Dec  8 13:11:46 2000
@@ -0,0 +1,43 @@
+#ifndef __ASM_EC3104_H
+#define __ASM_EC3104_H
+
+
+/*
+ * Most of the register set is at 0xb0ec0000 - 0xb0ecffff.
+ *
+ * as far as I've figured it out the register map is:
+ * 0xb0ec0000 - id string
+ * 0xb0ec0XXX - power management
+ * 0xb0ec1XXX - interrupt control
+ * 0xb0ec3XXX - ps2 port (touch pad on aero 8000)
+ * 0xb0ec6XXX - i2c
+ * 0xb0ec7000 - first serial port (proprietary connector on aero 8000)
+ * 0xb0ec8000 - second serial port
+ * 0xb0ec9000 - third serial port
+ * 0xb0eca000 - fourth serial port (keyboard controller on aero 8000)
+ * 0xb0eccXXX - GPIO
+ * 0xb0ecdXXX - GPIO
+ */
+
+#define EC3104_BASE	0xb0ec0000
+
+#define EC3104_SER4_DATA	(EC3104_BASE+0xa000)
+#define EC3104_SER4_IIR		(EC3104_BASE+0xa008)
+#define EC3104_SER4_MCR		(EC3104_BASE+0xa010)
+#define EC3104_SER4_LSR		(EC3104_BASE+0xa014)
+#define EC3104_SER4_MSR		(EC3104_BASE+0xa018)
+
+/*
+ * our ISA bus.  this seems to be real ISA.
+ */
+#define EC3104_ISA_BASE	0xa5000000
+
+#define EC3104_IRQ	11
+#define EC3104_IRQBASE	64
+
+#define EC3104_IRQ_SER1	EC3104_IRQBASE + 7
+#define EC3104_IRQ_SER2	EC3104_IRQBASE + 8
+#define EC3104_IRQ_SER3	EC3104_IRQBASE + 9
+#define EC3104_IRQ_SER4	EC3104_IRQBASE + 10
+
+#endif /* __ASM_EC3104_H */
diff -urNx CVS linuxsh/kernel/include/asm-sh/io.h linux-aero/include/asm-sh/io.h
--- linuxsh/kernel/include/asm-sh/io.h	Fri Dec  8 13:32:56 2000
+++ linux-aero/include/asm-sh/io.h	Fri Dec  8 14:38:23 2000
@@ -115,6 +115,8 @@
 #  include <asm/io_se.h>
 # elif defined(CONFIG_SH_FOOBAR)
 #  include <asm/io_hd64465.h>
+# elif defined(CONFIG_SH_EC3104)
+#  include <asm/io_ec3104.h>
 # elif defined(CONFIG_SH_UNKNOWN)
 #  include <asm/io_unknown.h>
 # else
diff -urNx CVS linuxsh/kernel/include/asm-sh/io_ec3104.h linux-aero/include/asm-sh/io_ec3104.h
--- linuxsh/kernel/include/asm-sh/io_ec3104.h	Wed Dec 31 16:00:00 1969
+++ linux-aero/include/asm-sh/io_ec3104.h	Fri Dec  8 14:38:23 2000
@@ -0,0 +1,54 @@
+#ifndef _ASM_SH_IO_EC3104_H
+#define _ASM_SH_IO_EC3104_H
+
+#include <asm/io_generic.h>
+#include <linux/types.h>
+
+extern unsigned char ec3104_inb(unsigned long port);
+extern unsigned short ec3104_inw(unsigned long port);
+extern unsigned long ec3104_inl(unsigned long port);
+
+extern void ec3104_outb(unsigned char value, unsigned long port);
+extern void ec3104_outw(unsigned short value, unsigned long port);
+extern void ec3104_outl(unsigned long value, unsigned long port);
+
+extern int ec3104_irq_demux(int irq);
+
+#ifdef __WANT_IO_DEF
+
+# define __inb			ec3104_inb
+# define __inw			ec3104_inw
+# define __inl			ec3104_inl
+# define __outb			ec3104_outb
+# define __outw			ec3104_outw
+# define __outl			ec3104_outl
+
+# define __inb_p		ec3104_inb
+# define __inw_p		ec3104_inw
+# define __inl_p		ec3104_inl
+# define __outb_p		ec3104_outb
+# define __outw_p		ec3104_outw
+# define __outl_p		ec3104_outl
+
+# define __insb			generic_insb
+# define __insw			generic_insw
+# define __insl			generic_insl
+# define __outsb		generic_outsb
+# define __outsw		generic_outsw
+# define __outsl		generic_outsl
+
+# define __readb		generic_readb
+# define __readw		generic_readw
+# define __readl		generic_readl
+# define __writeb		generic_writeb
+# define __writew		generic_writew
+# define __writel		generic_writel
+
+# define __isa_port2addr	generic_isa_port2addr
+# define __ioremap		generic_ioremap
+# define __ioremap_nocache	generic_ioremap_nocache
+# define __iounmap		generic_iounmap
+
+#endif
+
+#endif /* _ASM_SH_IO_EC3104_H */
diff -urNx CVS linuxsh/kernel/include/asm-sh/irq.h linux-aero/include/asm-sh/irq.h
--- linuxsh/kernel/include/asm-sh/irq.h	Fri Dec  8 13:32:57 2000
+++ linux-aero/include/asm-sh/irq.h	Fri Dec  8 14:38:30 2000
@@ -85,6 +85,8 @@
 # if defined(__SH4__)
 #  ifdef CONFIG_HD64465
 #   define NR_IRQS 80		/* HD64465_IRQBASE+16, see hd64465.h */
+#  elif defined (CONFIG_SH_EC3104)
+#   define NR_IRQS 96
 #  else
    /*
     * 48 = 32+16
@@ -208,6 +210,11 @@
 
 extern int hd64465_irq_demux(int irq);
 #define irq_demux(irq) hd64465_irq_demux(irq)
+
+#elif defined(CONFIG_SH_EC3104)
+
+extern int ec3104_irq_demux(int irq);
+#define irq_demux ec3104_irq_demux
 
 #else
 
diff -urNx CVS linuxsh/kernel/include/asm-sh/machvec.h linux-aero/include/asm-sh/machvec.h
--- linuxsh/kernel/include/asm-sh/machvec.h	Fri Dec  8 13:32:58 2000
+++ linux-aero/include/asm-sh/machvec.h	Fri Dec  8 14:38:23 2000
@@ -117,6 +117,11 @@
 # else
 #  define MACH_HD64465		0
 # endif
+# ifdef CONFIG_SH_EC3104
+#  define MACH_EC3104		1
+# else
+#  define MACH_EC3104		0
+# endif
 #endif
 
 #endif /* _ASM_SH_MACHVEC_H */
diff -urNx CVS linuxsh/kernel/include/asm-sh/serial-ec3104.h linux-aero/include/asm-sh/serial-ec3104.h
--- linuxsh/kernel/include/asm-sh/serial-ec3104.h	Wed Dec 31 16:00:00 1969
+++ linux-aero/include/asm-sh/serial-ec3104.h	Fri Dec  8 13:11:46 2000
@@ -0,0 +1,24 @@
+#include <asm/ec3104.h>
+/* Naturally we don't know the exact value but 115200 baud has a divisor
+ * of 9 and 19200 baud has a divisor of 52, so this seems like a good
+ * guess.  */
+#define BASE_BAUD (16800000 / 16)
+
+#define RS_TABLE_SIZE  3
+
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
+
+/* there is a fourth serial port with the expected values as well, but
+ * it's got the keyboard controller behind it so we can't really use it
+ * (without moving the keyboard driver to userspace, which doesn't sound
+ * like a very good idea) */
+#define STD_SERIAL_PORT_DEFNS			\
+	/* UART CLK   PORT IRQ     FLAGS        */			\
+	{ 0, BASE_BAUD, 0x11C00, EC3104_IRQBASE+7, STD_COM_FLAGS }, /* ttyS0 */	\
+	{ 0, BASE_BAUD, 0x12000, EC3104_IRQBASE+8, STD_COM_FLAGS }, /* ttyS1 */	\
+	{ 0, BASE_BAUD, 0x12400, EC3104_IRQBASE+9, STD_COM_FLAGS }, /* ttyS2 */
+
+#define SERIAL_PORT_DFNS STD_SERIAL_PORT_DEFNS
+
+/* XXX: This should be moved ino irq.h */
+#define irq_cannonicalize(x) (x)
diff -urNx CVS linuxsh/kernel/include/asm-sh/serial.h linux-aero/include/asm-sh/serial.h
--- linuxsh/kernel/include/asm-sh/serial.h	Fri Dec  8 13:32:58 2000
+++ linux-aero/include/asm-sh/serial.h	Fri Dec  8 14:39:54 2000
@@ -7,6 +7,13 @@
 #ifndef _ASM_SERIAL_H
 #define _ASM_SERIAL_H
 
+#include <linux/config.h>
+#include <linux/kernel.h>
+
+#ifdef CONFIG_SH_EC3104
+#include <asm/serial-ec3104.h>
+#else
+
 /*
  * This assumes you have a 1.8432 MHz clock for your UART.
  *
@@ -30,4 +37,5 @@
 /* XXX: This should be moved ino irq.h */
 #define irq_cannonicalize(x) (x)
 
+#endif
 #endif /* _ASM_SERIAL_H */

Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <re...@dr...>]

Philipp Rumpf wrote:
> 
> On Wed, Dec 06, 2000 at 08:44:16PM -0600, M. R. Brown wrote:
> > Hmm, somebody please help me confirm this, but I'm almost certain (based
> > on all of the specs I've seen) that the Dreamcast CPU runs at 200MHz.
> 
> correct
> 
> > Unfortunately I don't have the other specs (bus freq, etc.) in front of
> > me, but they're static as well (they're probably the standard SH4 ratio).
> 
> you can find those out by decoding FQCR.

FQCR ?

> 
> > Personally I'd rather lose the 1.5 seconds :)
> 
> For DC it's probably not that much of an issue - for embedded systems it
> definitely is.


Well yes. But the functions we are talking about are forms of auto
detect. Its my personal view that If you got an embedded system with
time critical applications and you use auto detect then you deserve
every trouble you get.

Well I'll make my proposal a bit more concrete.

1 Add the RTC to the mach_vec functions

mv_rtc_gettime
mv_rtc_settime

Any other part of the kernel is expected to use these functions to get
to the RTC. 

2 Add an constant to the macvector representing the timer_frequency.

mv_time_freq

This variable is either set by a constant or for the generic vector, by
auto detect.
The get_timer_freq functions is modified to fit the new RTC interface.

This way embedded systems can use a predefined value, and hence boot
fast. And lazy people can use the auto detect and pay the 1,5 sec
penalty. As an bonus we get nice modular code and move one step away
from the abyss.

I dont think its a good coding practise to go pass the RTC interface and
go directly at the hardware. I get a feeling that doing things like that
is a good way to introduse hard found bugs.

/Rene

Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Wed, Dec 06, 2000 at 08:44:16PM -0600, M. R. Brown wrote:
> Hmm, somebody please help me confirm this, but I'm almost certain (based
> on all of the specs I've seen) that the Dreamcast CPU runs at 200MHz. 

correct

> Unfortunately I don't have the other specs (bus freq, etc.) in front of
> me, but they're static as well (they're probably the standard SH4 ratio). 

you can find those out by decoding FQCR.

> Personally I'd rather lose the 1.5 seconds :)

For DC it's probably not that much of an issue - for embedded systems it
definitely is.

Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Thu, 7 Dec 2000, Philipp Rumpf wrote:

> On Wed, Dec 06, 2000 at 07:36:39PM -0600, M. R. Brown wrote:
> > On Thu, 7 Dec 2000, Rene Malmgren wrote:
> > > These funktions can be switched in att compile time or dynamicly at runtime.
> > > Then we simply write an rtc_gen.c and a rtc_dc.c, or perhaps even an
> > > rtc_sh3_gen.c, rtc_sh4_gen.c and an rtc_sh4_dc.c. Then we make all the other
> > > functions that use ther RTC access it through these two funktions. The
> > > get_timer_freq for instance. No modification has to be made to the generic
> > > code at all. You just simply chose the type of timer you want. We should
> > > consider doing the same thing to the timers aswell.
> 
> > Rene, what you just described is *exactly* what Phillip is planning to do.
> > He's moving generic SH4 RTC code into rtc.c so the generic SH4 target (and
> > any other machine that uses the SH4's builtin RTC) can use it.  Then he's
> > adding get_timer_frequency, get_rtc_time, and set_rtc_time to the machine
> 
> that's the main difference between Rene's proposal and mine:  I think using
> gettimeofday for the timer calibration is too expensive - it adds 1.5 seconds
> to our average boot time.  since many systems can use the 1/128 s - 1/64 s
> code or can determine their clocks statically (eg get it from firmware).
> 
> It's a tradeoff.  4 bytes of bloat versus 1.5 wasted seconds. (the actual code
> can be allocated in initmem).
> 
> Actually, if we start counting bytes, we might want to split up machvecs into
> initmem and permanent parts - but I'm not sure it's worth the obfuscation.
> 

Hmm, somebody please help me confirm this, but I'm almost certain (based
on all of the specs I've seen) that the Dreamcast CPU runs at 200MHz. 
Unfortunately I don't have the other specs (bus freq, etc.) in front of
me, but they're static as well (they're probably the standard SH4 ratio). 
I seriously doubt they would change in the future :).

Personally I'd rather lose the 1.5 seconds :)

M. R.

Re: [linuxsh-dev] Dreamcast RTC

[Philipp R. <pr...@pa...>]

On Wed, Dec 06, 2000 at 07:36:39PM -0600, M. R. Brown wrote:
> On Thu, 7 Dec 2000, Rene Malmgren wrote:
> > These funktions can be switched in att compile time or dynamicly at runtime.
> > Then we simply write an rtc_gen.c and a rtc_dc.c, or perhaps even an
> > rtc_sh3_gen.c, rtc_sh4_gen.c and an rtc_sh4_dc.c. Then we make all the other
> > functions that use ther RTC access it through these two funktions. The
> > get_timer_freq for instance. No modification has to be made to the generic
> > code at all. You just simply chose the type of timer you want. We should
> > consider doing the same thing to the timers aswell.

> Rene, what you just described is *exactly* what Phillip is planning to do.
> He's moving generic SH4 RTC code into rtc.c so the generic SH4 target (and
> any other machine that uses the SH4's builtin RTC) can use it.  Then he's
> adding get_timer_frequency, get_rtc_time, and set_rtc_time to the machine

that's the main difference between Rene's proposal and mine:  I think using
gettimeofday for the timer calibration is too expensive - it adds 1.5 seconds
to our average boot time.  since many systems can use the 1/128 s - 1/64 s
code or can determine their clocks statically (eg get it from firmware).

It's a tradeoff.  4 bytes of bloat versus 1.5 wasted seconds. (the actual code
can be allocated in initmem).

Actually, if we start counting bytes, we might want to split up machvecs into
initmem and permanent parts - but I'm not sure it's worth the obfuscation.


	Philipp

Re: [linuxsh-dev] Dreamcast RTC

[M. R. B. <ma...@uw...>]

On Thu, 7 Dec 2000, Rene Malmgren wrote:

> Let me give you an alternative solution witch might be better att hand.
> 
> I thnik we should adress the problem directly. Not try to patch our way
> arouind it.
> 
> So our problem is that different SH arch have different ways to talk to the
> RTC.
> So I prupose that we introduse an abstraction. Simply the get/set timeofday
> funktions.
> These funktions can be switched in att compile time or dynamicly at runtime.
> Then we simply write an rtc_gen.c and a rtc_dc.c, or perhaps even an
> rtc_sh3_gen.c, rtc_sh4_gen.c and an rtc_sh4_dc.c. Then we make all the other
> functions that use ther RTC access it through these two funktions. The
> get_timer_freq for instance. No modification has to be made to the generic
> code at all. You just simply chose the type of timer you want. We should
> consider doing the same thing to the timers aswell.
>

Rene, what you just described is *exactly* what Phillip is planning to do.
He's moving generic SH4 RTC code into rtc.c so the generic SH4 target (and
any other machine that uses the SH4's builtin RTC) can use it.  Then he's
adding get_timer_frequency, get_rtc_time, and set_rtc_time to the machine
vector, so that we can right customized routines for the Dreamcast.  Then
any machine that doesn't use the SH4's RTC can write their own.  That's
what the machvec system is for, and I do believe the DC port will be using
it extensively :).

I'm fleshing out the machvec for the DC now, it'll get rough when we start
working on the G2 bus and expansion port :P.  But if you check out
Documentation/sh/new-machine.txt it'll give you some ideas of the files
that are needed.

M. R.

Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <d9...@ef...>]

----- Original Message -----
From: "Philipp Rumpf" <pr...@pa...>
To: "M. R. Brown" <ma...@uw...>
Cc: "Rene Malmgren" <re...@dr...>
Sent: Tuesday, December 05, 2000 10:58 PM
Subject: Re: [linuxsh-dev] Dreamcast RTC


> On Tue, Dec 05, 2000 at 02:36:11PM -0600, M. R. Brown wrote:
> > Either something happened to my mail or my filters are broken, but I
> > seemed to miss most of this thread, any chance I can get a recap of what
> > was discussed?
>
> > >From the latest e-mail, I can see that you were debating on where the
RTC
> > code should go.  I agree with Rene that the code in time.c is
bastardized,
> > and not necessarily portable across SH's (well just the DC that I know
>
> It makes use of hardware not available on all CPUs - I was working under
the
> (incorrect) premise that since the RTC hardware exists on all SH-4 chips,
it
> would be functional on all of them as well.
>
> So here's my first proposal of how to fix it:
>
> add a mv_get_timer_freq function, which is one of three things:
> 1. a function returning a constant, for machines on which you know the
exact
> frequencies used.
> 2. my 1/128 s - 1/64 s RTC calibration function
> 3. machine-dependent code that calibrates the TMU freq using whatever
known
> clock is available
>
> add machvec functions for gettimeofday/settimeofday
>
> The default implementations of 2., gettimeofday, and settimeofday could be
> in arch/sh/kernel/rtc.c, nicely isolated from the TMU code.
>
> Any obvious breakage (otherwise I'll do a patch tomorrow) ?

Let me give you an alternative solution witch might be better att hand.

I thnik we should adress the problem directly. Not try to patch our way
arouind it.

So our problem is that different SH arch have different ways to talk to the
RTC.
So I prupose that we introduse an abstraction. Simply the get/set timeofday
funktions.
These funktions can be switched in att compile time or dynamicly at runtime.
Then we simply write an rtc_gen.c and a rtc_dc.c, or perhaps even an
rtc_sh3_gen.c, rtc_sh4_gen.c and an rtc_sh4_dc.c. Then we make all the other
functions that use ther RTC access it through these two funktions. The
get_timer_freq for instance. No modification has to be made to the generic
code at all. You just simply chose the type of timer you want. We should
consider doing the same thing to the timers aswell.

>
> > of), but then there's a point where you can't say what's standard on the
> > SH (which is why the rest of time.c doesn't work on the DC, which is why
I
> > think adding timer/RTC/irq items to the generic machvec would make the
> > most sense.
>
> You lost me at "the rest of time.c".  Surely the TMU timers work ?

Yes the TMU works on the DC. But I dont know if its the same way.

Could you pleas describe the init_timer function breafly an what it does
just around the get_timer_freq.

As I see it it sets some busfreq and som other stuff. But I have no idee
what the DC values are supose to be.

>
> > Since I somehow missed the thread, I added some comments to your
responses
>
> Some of the messages were (accidentally ?) sent privately.  If Rene
doesn't
> mind, I'll forward my responses to you.

No mind.

>
> > On Tue, 5 Dec 2000, Rene Malmgren wrote:
> > The DC has _all_ the traits of an SH4 processor with the notable
exception
> > of a disabled RTC.  It doesn't make sense to conditionalize or exclude
it
>
> where "disabled RTC" means there is no crystal connected to the RTC pins ?

Most likely yes. It's standing still.

Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <d9...@ef...>]

----- Original Message -----
From: "Philipp Rumpf" <pr...@pa...>
To: "M. R. Brown" <ma...@uw...>
Cc: "Rene Malmgren" <re...@dr...>
Sent: Tuesday, December 05, 2000 10:58 PM
Subject: Re: [linuxsh-dev] Dreamcast RTC


> On Tue, Dec 05, 2000 at 02:36:11PM -0600, M. R. Brown wrote:
> > Either something happened to my mail or my filters are broken, but I
> > seemed to miss most of this thread, any chance I can get a recap of what
> > was discussed?
>
> > >From the latest e-mail, I can see that you were debating on where the
RTC
> > code should go.  I agree with Rene that the code in time.c is
bastardized,
> > and not necessarily portable across SH's (well just the DC that I know
>
> It makes use of hardware not available on all CPUs - I was working under
the
> (incorrect) premise that since the RTC hardware exists on all SH-4 chips,
it
> would be functional on all of them as well.
>
> So here's my first proposal of how to fix it:
>
> add a mv_get_timer_freq function, which is one of three things:
> 1. a function returning a constant, for machines on which you know the
exact
> frequencies used.
> 2. my 1/128 s - 1/64 s RTC calibration function
> 3. machine-dependent code that calibrates the TMU freq using whatever
known
> clock is available
>
> add machvec functions for gettimeofday/settimeofday
>
> The default implementations of 2., gettimeofday, and settimeofday could be
> in arch/sh/kernel/rtc.c, nicely isolated from the TMU code.
>
> Any obvious breakage (otherwise I'll do a patch tomorrow) ?

Let me give you an alternative solution witch might be better att hand.

I thnik we should adress the problem directly. Not try to patch our way
arouind it.

So our problem is that different SH arch have different ways to talk to the
RTC.
So I prupose that we introduse an abstraction. Simply the get/set timeofday
funktions.
These funktions can be switched in att compile time or dynamicly at runtime.
Then we simply write an rtc_gen.c and a rtc_dc.c, or perhaps even an
rtc_sh3_gen.c, rtc_sh4_gen.c and an rtc_sh4_dc.c. Then we make all the other
functions that use ther RTC access it through these two funktions. The
get_timer_freq for instance. No modification has to be made to the generic
code at all. You just simply chose the type of timer you want. We should
consider doing the same thing to the timers aswell.

>
> > of), but then there's a point where you can't say what's standard on the
> > SH (which is why the rest of time.c doesn't work on the DC, which is why
I
> > think adding timer/RTC/irq items to the generic machvec would make the
> > most sense.
>
> You lost me at "the rest of time.c".  Surely the TMU timers work ?

Yes the TMU works on the DC. But I dont know if its the same way.

Could you pleas describe the init_timer function breafly an what it does
just around the get_timer_freq.

As I see it it sets some busfreq and som other stuff. But I have no idee
what the DC values are supose to be.

>
> > Since I somehow missed the thread, I added some comments to your
responses
>
> Some of the messages were (accidentally ?) sent privately.  If Rene
doesn't
> mind, I'll forward my responses to you.

No mind.

>
> > On Tue, 5 Dec 2000, Rene Malmgren wrote:
> > The DC has _all_ the traits of an SH4 processor with the notable
exception
> > of a disabled RTC.  It doesn't make sense to conditionalize or exclude
it
>
> where "disabled RTC" means there is no crystal connected to the RTC pins ?

Most likely yes. It's standing still.

Re: [linuxsh-dev] Dreamcast RTC

[Rene M. <re...@dr...>]

Philipp Rumpf wrote:
> 
> >
> > If you ask me the best way is to use the Make scripts.
> >
> > Adding a CONFIG_SH_DREAMCAST to the script and the adding
> 
> obviously
> 
> > and extra (binary preselected) option depending on it called
> > CONFIG_SH_USE_DREAMCAST_RTC. Then use std #ifdefs to switch at compile
> 
> #ifdef is ugly.  ifdef in Makefiles is a lot nicer.

I cant say I have an opinion on the subject. Exept that the later needs
more work. But sure its nicer.

> 
> > time. Either you are building for the DC or you are not. And there is no
> 
> I agree, but Niibe did integrate "generic build" support and I think it's
> impolite to refuse to co-operate with that.

From my point of view the GENERIC platform is a nice idea and if people
think we should extend it to involve RTC support too fine by me. But I
think we should keep the DC out of it at least until the DC-port is
complete. The DC is a hack as it is and has very little in common with
all the other platforms. Not to mention the obvious risk that we break
things again (and there by creating more trouble for everyone). 

> 
> > point involving the other platforms. Moving the rtc to a separate file
> > is a good idear. But then again. To me it looks like the entire time.c
> > has to be rewritten to fit the DC. Its not just the get_rtc_time thats
> > the problem but also  get_timer_frequency(void) and others.
> 
> Why ?  The rest of time.c uses standard onchip SH-4 features, and I think
> it should work well even on DC (I don't have one though, want to send me
> one ;) ?).

Well because the entire time.c seams to me like a hack...
And they all use std SH rtc the hardware way. So when the wait for a
1/128s on a DC they will wait forever, since there is no functioning RTC
there.

/Rene

Re: [linuxsh-dev] SH-4 cache performance improvement

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

At 15:20 00/12/02 +0000, Philipp Rumpf wrote:
>On Sun, Dec 03, 2000 at 12:08:15AM +0900, SUGIOKA Toshinobu wrote:
>> current __flush_page_to_ram invalidates data cache of the page,
>> but I think write back is sufficient.  
>> 
>> I'm not sure whether this patch causes synonym problem.
>
>flush_page_to_ram implies that the page is not going to be accessed using
>the kernel mapping for a while, so a writeback should be sufficient in
>practice.  Using ocbp ratehr than ocbwb should definitely be correct and
>might be just as fast, have you tried it ?
>

I tried and found that 'ocbp' works as fast as 'ocbwb'.

According to the DaveM's documentation (Documents/cachetlb.txt)
flush_page_to_ram should write back and invalidate the D-cache.
So 'ocbp' should be correct.


----
SUGIOKA Toshinobu

Re: [linuxsh-dev] SH-4 cache performance improvement

[Philipp R. <pr...@pa...>]

On Sat, Dec 02, 2000 at 03:20:38PM +0000, Philipp Rumpf wrote:
> Looks fine to me;  unfortunately, several people (including me) still seem
> to be seeing what looks like random corruption of kernel memory (which isn't
> affected by inconsistent vipt caches), so keeping the paranoid versions of

I found the reason for the corruption I was seeing and everything seems to
work now (I'm actually typing this on my SuperH machine!).  dwmw2, what about
yours ?

Re: [linuxsh-dev] SH-4 cache performance improvement

[Philipp R. <pr...@pa...>]

On Sun, Dec 03, 2000 at 12:08:15AM +0900, SUGIOKA Toshinobu wrote:
> current __flush_page_to_ram invalidates data cache of the page,
> but I think write back is sufficient.  
> 
> I'm not sure whether this patch causes synonym problem.

flush_page_to_ram implies that the page is not going to be accessed using
the kernel mapping for a while, so a writeback should be sufficient in
practice.  Using ocbp ratehr than ocbwb should definitely be correct and
might be just as fast, have you tried it ?

> Is this approach correct ?

Looks fine to me;  unfortunately, several people (including me) still seem
to be seeing what looks like random corruption of kernel memory (which isn't
affected by inconsistent vipt caches), so keeping the paranoid versions of
the cache handling routines might be a good idea.