linuxsh-dev

[linuxsh-dev] Slight cleanup of CCR definitions.

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

This makes the definitions slightly easier to read (and to muck around with 
when you're debugging DMA problems)

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.338
diff -u -r1.338 ChangeLog
--- ChangeLog	2001/09/06 04:01:38	1.338
+++ ChangeLog	2001/09/10 08:50:37
@@ -1,3 +1,8 @@
+2001-09-10  David Woodhouse <dw...@in...>
+
+	* arch/sh/mm/cache-sh3.c: Clearer definitions of CCR_CACHE_VAL and
+	CCR_CACHE_INIT.
+
 2001-09-03  NIIBE Yutaka  <gn...@m1...>
 
 	* include/asm-sh/keyboard.h (kbd_rate): Removed.
Index: arch/sh/mm/cache-sh3.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh3.c,v
retrieving revision 1.5
diff -u -r1.5 cache-sh3.c
--- arch/sh/mm/cache-sh3.c	2001/08/24 15:31:41	1.5
+++ arch/sh/mm/cache-sh3.c	2001/09/10 08:50:37
@@ -20,10 +20,17 @@
 #include <asm/pgalloc.h>
 #include <asm/mmu_context.h>
 
+
 #define CCR		0xffffffec	/* Address of Cache Control Register */
-#define CCR_CACHE_VAL	0x00000005	/* 8k-byte cache, P1-wb, enable */
-#define CCR_CACHE_INIT	0x0000000d	/* 8k-byte cache, CF, P1-wb, enable */
-#define CCR_CACHE_ENABLE	 1
+
+#define CCR_CACHE_CE	0x01	/* Cache Enable */
+#define CCR_CACHE_WT	0x02	/* Write-Through (for P0,U0,P3) (else writeback) */
+#define CCR_CACHE_CB	0x04	/* Write-Back (for P1) (else writethrough) */
+#define CCR_CACHE_CF	0x08	/* Cache Flush */
+#define CCR_CACHE_RA	0x20	/* RAM mode */
+
+#define CCR_CACHE_VAL	(CCR_CACHE_CB|CCR_CACHE_CE)	/* 8k-byte cache, P1-wb, enable */
+#define CCR_CACHE_INIT	(CCR_CACHE_CF|CCR_CACHE_VAL)	/* 8k-byte cache, CF, P1-wb, enable */
 
 #define CACHE_OC_ADDRESS_ARRAY 0xf0000000
 #define CACHE_VALID	  1
@@ -131,7 +138,7 @@
 
 	jump_to_P2();
 	ccr = ctrl_inl(CCR);
-	if (ccr & CCR_CACHE_ENABLE)
+	if (ccr & CCR_CACHE_CE)
 		/*
 		 * XXX: Should check RA here. 
 		 * If RA was 1, we only need to flush the half of the caches.

--
dwmw2

[linuxsh-dev] 2.4.10-pre6

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

Will be installed tomorrow.

The update has been included, so the difference agaist mainline become
small.
-- 

[linuxsh-dev] MR-SHPC PCMCIA bridge.

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

Has anyone done a proper driver for the MR-SHPC bridge, or is there only 
the cf-enabler hack? Does anyone have English docs for the chip? I think I 
can work it all out from the tables, but I'd feel happier if I could read 
the words too :)


--
dwmw2

Re: [linuxsh-dev] Compiling Linux kernel on ST407750 Overdrive board

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

Hi there

There are a couple of problem here:

 - It looks like you are using an older version of the gcc tools.
   The building-source.php3 page should probably be maked as obsolete
   now, as most people have now migrated to the newer tools described
   in:
     http://linuxsh.sourceforge.net/docs/abe/20010320-gcc2.97/README_E.ph=
p3
   (follow the links at the end of the 'Documents' page on linuxsh.sf.net=
).

 - A few months ago we decided to drop support for the 7750 Overdrive
   in the Linux kernel sources (we really don't want to have to continue
   to support it any longer than necessary - especially now we have ST40
   based boards available). So what is in the CVS repository on SourceFor=
ge
   is only some of the code needed.

You are probably better off looking at:
  ftp://ftp.linuxsh.st.com/pub/linuxsh/release-0.4
There you will find RPMS and SRPMs for the compiler, and kernel, which ha=
s
already been patched to support the 7750 Overdrive.

Good luck

Stuart

On Sep 7, 12:21pm, kl...@fu... wrote:
> Subject: [linuxsh-dev] Compiling Linux kernel on ST407750 Overdrive boa=
rd
> Hi,
> =

> I hope this is the correct mailinglist for this kind of question.
> =

> We are currently working on porting the Linux kernel to a ST407750 Over=
drive board. We have found the document (http://linuxsh.sourceforge.net/d=
ocs/building-source.php3) describing how to build the kernel for SH proce=
ssors. We do, though, have some problems.
> =

> We use the following kernel configuration:
> =

> CONFIG_SH_STB1_OVERDRIVE=3Dy
> CONFIG_CPU_SUBTYPE_SH7750=3Dy
> CONFIG_CPU_SH4=3Dy
> =

> along with default configuration. The problem seems to be that the gcc =
version does not support the -m4-nofpu option. We have tried to change th=
is in kernel/arch/sh/Makefile:
> diff Makefile_org Makefile_changed
> 49,50c49,50
> < CFLAGS                +=3D -m4-nofpu
> < AFLAGS                +=3D -m4-nofpu
> ---
> > CFLAGS                +=3D -m4
> > AFLAGS                +=3D -m4
> =

> but this give rise to other problems.
> =

> As we need the Overdrive board as a reference for other ports, we would=
 like to know if there is a "safe/easy" way to make the kernel work on th=
e Overdrive board. We also experience problems in getting the sh-ipl+g to=
 compile. Which version of gcc, binutils and the kernel should we use and=
 where should we obtain them ? Is the above mentioned document still up-t=
o-date?
> =

> =

> thank you,
> =

> Kristian Sorensen
> =

> ----
>   Kristian Lykkegaard S=F8rensen  <kl...@fu...>
>   Software Architect, M.Sc.
> =

> =

> =

> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> =

> =

>-- End of excerpt from kl...@fu...

[linuxsh-dev] Compiling Linux kernel on ST407750 Overdrive board

[<kl...@fu...>]

Hi,

I hope this is the correct mailinglist for this kind of question.

We are currently working on porting the Linux kernel to a ST407750 =
Overdrive board. We have found the document =
(http://linuxsh.sourceforge.net/docs/building-source.php3) describing =
how to build the kernel for SH processors. We do, though, have some =
problems.

We use the following kernel configuration:

CONFIG_SH_STB1_OVERDRIVE=3Dy
CONFIG_CPU_SUBTYPE_SH7750=3Dy
CONFIG_CPU_SH4=3Dy

along with default configuration. The problem seems to be that the gcc =
version does not support the -m4-nofpu option. We have tried to change =
this in kernel/arch/sh/Makefile:
diff Makefile_org Makefile_changed
49,50c49,50
< CFLAGS                +=3D -m4-nofpu
< AFLAGS                +=3D -m4-nofpu
---
> CFLAGS                +=3D -m4
> AFLAGS                +=3D -m4

but this give rise to other problems.

As we need the Overdrive board as a reference for other ports, we would =
like to know if there is a "safe/easy" way to make the kernel work on =
the Overdrive board. We also experience problems in getting the sh-ipl+g =
to compile. Which version of gcc, binutils and the kernel should we use =
and where should we obtain them ? Is the above mentioned document still =
up-to-date?


thank you,

Kristian Sorensen

----
  Kristian Lykkegaard S=F8rensen  <kl...@fu...>
  Software Architect, M.Sc.

Re: [linuxsh-dev] Cassiopeia A10

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

* Cory Watson <gp...@ca...> on Wed, Sep 05, 2001:

> Hi... I've got one of these buggers, and it needs Linux.  Am I in the right 
> place? ;)
> 

Uh, that depends.  Are you trying to get Linux booting on your A10?  Have
you been to the websites (http://linuxsh.sf.net, check the Links section)?
Have you read the mailing list archives?

Seems to me that'd be a good way of finding out.

M. R.

[linuxsh-dev] Cassiopeia A10

[Cory W. <gp...@ca...>]

Hi... I've got one of these buggers, and it needs Linux.  Am I in the right 
place? ;)

Re: [linuxsh-dev] Configurable Command Line (parameter block?)

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

js...@mv... said:
> +      while (!(*STATUS_REGISTER & 0x60)); 

Please could we express this as

	int timeout = 10000;
	while (!(*STATUS_REGISTER & 0x60) && timeout--)
		;




--
dwmw2

[linuxsh-dev] Configurable Command Line (parameter block?)

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

Jeremy Siegel wrote:
 > Rather than the entire parameter block we copy only the kernel command
 > line, made configurable (with a copy in misc.c itself so zImage is still
 > built w/o the empty_zero_page).  This allows kernel config to force the
 > command line regardless of the bootloader, or to not have one and depend
 > on the bootloader as now.  (Or to use sh-ipl+g to load w/o having to set
 > up the command line using gdb commands.)

I think it's good idea to have hard-coded default parameters, and make
them configurable.  I don't think it's good to "force" the parameters.
It should be overridden at run-time.

 > (Note that the following patch also includes code in misc.c to display
 > the "Uncompressing Linux..." message w/o the SH BIOS, though it's now
 > under Solution Engine config flags only.)

This part is OK for me.  Perhaps, using another config option would be
good (CONFIG_SERIAL_CONSOLE and someting), instead of target machine.

Besides, for the implementation of default parameters for zImage, 
I think it could be implemented the file(s) under arch/sh/boot/.

 > --- kernel/arch/sh/kernel/head.S	Fri Jul 27 04:48:29 2001
 > +++ test/arch/sh/kernel/head.S	Tue Sep  4 14:13:49 2001

I think touching beyond arch/sh/boot/ is irrelevant for this purpose.

How about following?

  (a) Introduce parameter block something like David Woodhouse suggested.
  (b) Provide the config option to build "zImage + parameter block",
      say, zImage+parms, and provide options for default paremeters
      to build parameters block.

Users can use zImage+parms with no boot loader, use zImage with boot
loader, or use zImage+parms with boot loader which may override params
at run-time.
-- 

[linuxsh-dev] Configurable Command Line (parameter block?)

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

Re: [linuxsh-dev] Parameter block with zImage.

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

gn...@m1... said:
>  For the record.  Our version of LILO does.  So does our version of
> etherboot.  But they could be changed, as it is not a big deal.

Well, there's no particular reason to change it, I suppose - it just seemed
neater at the time to change the kernel to load the parameter block near the
zImage than to change the bootloader. I'll fix up my RedBoot defaults to 
match the kernel.

--
dwmw2

[linuxsh-dev] Parameter block with zImage.

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

David Woodhouse wrote:
 > Is anyone actually doing that?

For the record.  Our version of LILO does.  So does our version of
etherboot.  But they could be changed, as it is not a big deal.
-- 

Re: [linuxsh-dev] Parameter block with zImage.

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

du...@se... said:
> I'm using Redboot with Yaegashi Takeshi's kernel boot loader support
> added. This copies a run time configurable parameter block to a
> specified address. I guess I could move this copy location to 0x210000
> instead of 0x0.  It would just get copied twice (to 0x210000 and then
> to 0x0), but that may not be a big deal.  I guess I don't object to
> moving the parameter block location, as long as there is still a way
> to copy parameter blocks at run time. 

Hmmm. It occurs to me that I could probably have done the same instead of 
hacking the zImage code. I was assuming that RedBoot required the first 
page of memory, but it actually sets up the parameter block after disabling 
interrupts and flushing caches, etc - just before jumping into the kernel. 
So I should be able to just specify '-b 0' to the exec command.


--
dwmw2

RE: [linuxsh-dev] Parameter block with zImage.

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

I'm using Redboot with Yaegashi Takeshi's kernel boot loader support added.
This copies a run time configurable parameter block to a specified address.
I guess I could move this copy location to 0x210000 instead of 0x0.  It
would just get copied twice (to 0x210000 and then to 0x0), but that may not
be a big deal.  I guess I don't object to moving the parameter block
location, as long as there is still a way to copy parameter blocks at run
time.

Dustin.

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of David
> Woodhouse
> Sent: Monday, September 03, 2001 9:26 AM
> To: linuxsh-dev
> Subject: [linuxsh-dev] Parameter block with zImage.
>
>
> When we load a zImage, we load it to 0x210000 and it decompresses the real
> kernel image to 0x1000.
>
> The parameter block is in the first page of memory, and the zImage
> decompression code doesn't touch it. The bootloader is expected
> to load the
> zImage to 0x210000 and the parameters to 0x0.
>
> Does anyone actually pass parameters to the kernel this way? I'd like to
> change the address at which the zImage expects the parameter block to be
> loaded - to load it to the beginning of the zImage just as we would
> normally load it at the beginning of a vmlinux.
>
> The attached patch does this - moves the entry point of the zImage to
> 0x211000 and makes it copy the parameter block from 0x210000 to 0 after
> decompressing the kernel image to 0x1000 as before.
>
> It puts a jmp insn in at 0x210000 for backward compatibility with
> bootloaders which don't look at the entry point of the loaded image.
>
> This would break parameter passing for anyone who is currently using a
> zImage and passing parameters by putting the param block at the beginning
> of memory.
>
> Is anyone actually doing that?
>
> Index: arch/sh/boot/compressed/Makefile
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/Makefile,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile
> --- arch/sh/boot/compressed/Makefile	2000/10/03 00:47:32	1.6
> +++ arch/sh/boot/compressed/Makefile	2001/07/04 13:38:43
> @@ -19,8 +19,9 @@
>  # ZIMAGE_OFFSET is the load offset of the compression loader
>  #
>  ZIMAGE_OFFSET = $(shell printf "0x%8x"
> $$[0x80000000+0x$(CONFIG_MEMORY_START)+0x200000+0x10000])
> +ZIMAGE_ENTRY = $(shell printf "0x%8x" $$[$(ZIMAGE_OFFSET)+0x1000])
>
> -ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZLDFLAGS)
> +ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZLDFLAGS) -e $(ZIMAGE_ENTRY)
>
>  all: vmlinux
>
> Index: arch/sh/boot/compressed/head.S
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/head.S,v
> retrieving revision 1.5
> diff -u -r1.5 head.S
> --- arch/sh/boot/compressed/head.S	2000/12/24 23:52:56	1.5
> +++ arch/sh/boot/compressed/head.S	2001/07/04 13:38:44
> @@ -8,7 +8,19 @@
>
>  #include <linux/linkage.h>
>
> +	.global params
> +
> +params:
> +	mov.l	startup_addr, r0
> +	jmp	@r0
> +
> +startup_addr:
> +	.long	startup
> +
> +.org	0x1000
> +
>  	.global	startup
> +
>  startup:
>  	/* Load initial status register */
>  	mov.l   init_sr, r1
> Index: arch/sh/boot/compressed/misc.c
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/misc.c,v
> retrieving revision 1.5
> diff -u -r1.5 misc.c
> --- arch/sh/boot/compressed/misc.c	2000/07/20 15:55:00	1.5
> +++ arch/sh/boot/compressed/misc.c	2001/07/04 13:38:44
> @@ -96,6 +96,7 @@
>  extern int _end;
>  static unsigned long free_mem_ptr;
>  static unsigned long free_mem_end_ptr;
> +extern int params;
>
>  #define HEAP_SIZE             0x10000
>
> @@ -224,6 +225,18 @@
>  long user_stack [STACK_SIZE];
>  long* stack_start = &user_stack[STACK_SIZE];
>
> +void copy_param_block(void)
> +{
> +	int i;
> +
> +	unsigned long *src = (unsigned long *)&params;
> +	unsigned long *dst = (unsigned long *)&_text + 0x20000000;
> +
> +	for(i=0; i<0x1000/4; i++) {
> +		dst[i]=src[i];
> +	}
> +}
> +
>  void decompress_kernel(void)
>  {
>  	output_data = 0;
> @@ -231,6 +244,7 @@
>  	free_mem_ptr = (unsigned long)&_end;
>  	free_mem_end_ptr = free_mem_ptr + HEAP_SIZE;
>
> +	copy_param_block();
>  	makecrc();
>  	puts("Uncompressing Linux... ");
>  	gunzip();
>
> --
> dwmw2
>
>
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>

[linuxsh-dev] Parameter block with zImage.

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

When we load a zImage, we load it to 0x210000 and it decompresses the real
kernel image to 0x1000.

The parameter block is in the first page of memory, and the zImage
decompression code doesn't touch it. The bootloader is expected to load the
zImage to 0x210000 and the parameters to 0x0.

Does anyone actually pass parameters to the kernel this way? I'd like to 
change the address at which the zImage expects the parameter block to be 
loaded - to load it to the beginning of the zImage just as we would 
normally load it at the beginning of a vmlinux.

The attached patch does this - moves the entry point of the zImage to 
0x211000 and makes it copy the parameter block from 0x210000 to 0 after 
decompressing the kernel image to 0x1000 as before. 

It puts a jmp insn in at 0x210000 for backward compatibility with 
bootloaders which don't look at the entry point of the loaded image. 

This would break parameter passing for anyone who is currently using a 
zImage and passing parameters by putting the param block at the beginning 
of memory. 

Is anyone actually doing that?

Index: arch/sh/boot/compressed/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- arch/sh/boot/compressed/Makefile	2000/10/03 00:47:32	1.6
+++ arch/sh/boot/compressed/Makefile	2001/07/04 13:38:43
@@ -19,8 +19,9 @@
 # ZIMAGE_OFFSET is the load offset of the compression loader
 #
 ZIMAGE_OFFSET = $(shell printf "0x%8x" $$[0x80000000+0x$(CONFIG_MEMORY_START)+0x200000+0x10000])
+ZIMAGE_ENTRY = $(shell printf "0x%8x" $$[$(ZIMAGE_OFFSET)+0x1000])
 
-ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZLDFLAGS)
+ZLINKFLAGS = -Ttext $(ZIMAGE_OFFSET) $(ZLDFLAGS) -e $(ZIMAGE_ENTRY)
 
 all: vmlinux
 
Index: arch/sh/boot/compressed/head.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/head.S,v
retrieving revision 1.5
diff -u -r1.5 head.S
--- arch/sh/boot/compressed/head.S	2000/12/24 23:52:56	1.5
+++ arch/sh/boot/compressed/head.S	2001/07/04 13:38:44
@@ -8,7 +8,19 @@
 
 #include <linux/linkage.h>
 
+	.global params
+	
+params:
+	mov.l	startup_addr, r0
+	jmp	@r0
+
+startup_addr:
+	.long	startup
+	
+.org	0x1000
+
 	.global	startup
+
 startup:
 	/* Load initial status register */
 	mov.l   init_sr, r1
Index: arch/sh/boot/compressed/misc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/boot/compressed/misc.c,v
retrieving revision 1.5
diff -u -r1.5 misc.c
--- arch/sh/boot/compressed/misc.c	2000/07/20 15:55:00	1.5
+++ arch/sh/boot/compressed/misc.c	2001/07/04 13:38:44
@@ -96,6 +96,7 @@
 extern int _end;
 static unsigned long free_mem_ptr;
 static unsigned long free_mem_end_ptr;
+extern int params;
  
 #define HEAP_SIZE             0x10000
 
@@ -224,6 +225,18 @@
 long user_stack [STACK_SIZE];
 long* stack_start = &user_stack[STACK_SIZE];
 
+void copy_param_block(void)
+{
+	int i;
+
+	unsigned long *src = (unsigned long *)&params;
+	unsigned long *dst = (unsigned long *)&_text + 0x20000000;
+
+	for(i=0; i<0x1000/4; i++) {
+		dst[i]=src[i];
+	}
+}
+
 void decompress_kernel(void)
 {
 	output_data = 0;
@@ -231,6 +244,7 @@
 	free_mem_ptr = (unsigned long)&_end;
 	free_mem_end_ptr = free_mem_ptr + HEAP_SIZE;
 
+	copy_param_block();
 	makecrc();
 	puts("Uncompressing Linux... ");
 	gunzip();

--
dwmw2

[linuxsh-dev] 2.4.10-pre4

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

Will be installed tomorrow.

Finally, cache related changes are in.
-- 

[linuxsh-dev] gcc-3.1 bootstrapped

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

Hi,

Now gcc-3.1 (current CVS) can bootstrap again on SH. The SH
local patches for that are put as

  http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010902.diff

The essential parts are already sent to gcc mailing list and
waiting the review.

BTW, I found an unalignment bug in GNU libc. I think it's rare
to be hit with this problem, but all versions of libc except
current CVS have the same bug. I attach the following tiny
patch for it.

	kaz
--
	* sysdeps/unix/sysv/linux/sh/sysdep.S: Align errno.

Index: sysdep.S
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/sh/sysdep.S,v
retrieving revision 1.2
diff -u -r1.2 sysdep.S
--- sysdep.S	2001/07/06 04:56:20	1.2
+++ sysdep.S	2001/08/20 03:10:08
@@ -21,6 +21,7 @@
 /* We define errno here, to be consistent with Linux/i386.  */
 
 	.section .bss
+	.align 2
 	.globl C_SYMBOL_NAME(errno)
 	.type C_SYMBOL_NAME(errno), @object
 	.size C_SYMBOL_NAME(errno), 4

[linuxsh-dev] Dreamcast RTC routines

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

Here's preliminary support for the Dreamcast AICA RTC registers - it adds
the appropiate calls to the machvec which allows the timer frequency and
RTC query stuff to work as intended.

I'll be writing mc146818rtc stuff in a bit.

M. R.

2000-08-31  M. R. Brown <mr...@0x...>

	* arch/sh/kernel/Makefile: Add dependency for rtc-aica.o for
	CONFIG_SH_DREAMCAST.
	* arch/sh/kernel/mach_dc.c: Add prototypes and pointers for the AICA
	RTC routines to the machvec.
	* arch/sh/kernel/time.c (time_init): Remove checks for
	MACH_DREAMCAST as we can just use the RTC routines defined in the
	machvec.
	* arch/sh/kernel/rtc-aica.c: New file.

Index: Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile	2001/08/24 12:38:19	1.30
+++ Makefile	2001/09/01 06:08:03
@@ -74,7 +74,7 @@
 obj-$(CONFIG_HD64465)		+= setup_hd64465.o io_hd64465.o hd64465_gpio.o
 obj-$(CONFIG_SH_DMIDA)		+= mach_dmida.o
 obj-$(CONFIG_SH_EC3104)         += setup_ec3104.o io_ec3104.o mach_ec3104.o
-obj-$(CONFIG_SH_DREAMCAST)	+= mach_dc.o setup_dc.o io_dc.o
+obj-$(CONFIG_SH_DREAMCAST)	+= mach_dc.o setup_dc.o io_dc.o rtc-aica.o
 
 ifeq ($(CONFIG_SH_GENERIC),y)
 obj-y		+= $(machine-specific-objs)
Index: mach_dc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_dc.c,v
retrieving revision 1.4
diff -u -r1.4 mach_dc.c
--- mach_dc.c	2001/05/24 05:09:16	1.4
+++ mach_dc.c	2001/09/01 06:08:03
@@ -1,10 +1,11 @@
 /*
- *	$Id: mach_dc.c,v 1.4 2001/05/24 05:09:16 mrbrown Exp $
+ *	$Id: mach_dc.c,v 1.2 2001/09/01 04:45:08 mrbrown Exp $
  *	SEGA Dreamcast machine vector
  */
 
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/time.h>
 
 #include <asm/machvec.h>
 #include <asm/machvec_init.h>
@@ -16,6 +17,10 @@
 void __init setup_dreamcast(void);
 void __init dreamcast_pcibios_init(void);
 
+/* Custom Dreamcast RTC routines */
+void aica_rtc_gettimeofday(struct timeval *tv);
+int aica_rtc_settimeofday(const struct timeval *tv);
+
 /*
  * The Machine Vector
  */
@@ -59,6 +64,9 @@
 	mv_init_arch:		setup_dreamcast,
 	mv_isa_port2addr:	dreamcast_isa_port2addr,
 	mv_irq_demux:		systemasic_irq_demux,
+
+	mv_rtc_gettimeofday:	aica_rtc_gettimeofday,
+	mv_rtc_settimeofday:	aica_rtc_settimeofday,
 
 	mv_hw_dreamcast:	1,
 };
Index: time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.29
diff -u -r1.29 time.c
--- time.c	2001/07/23 10:43:42	1.29
+++ time.c	2001/09/01 06:08:03
@@ -1,4 +1,4 @@
-/* $Id: time.c,v 1.29 2001/07/23 10:43:42 gniibe Exp $
+/* $Id: time.c,v 1.2 2001/09/01 04:45:48 mrbrown Exp $
  *
  *  linux/arch/sh/kernel/time.c
  *
@@ -359,17 +359,11 @@
 #endif
 #endif
 
-	if (MACH_DREAMCAST)
-		xtime.tv_sec = xtime.tv_usec = 0;
-	else
-		rtc_gettimeofday(&xtime);
+	rtc_gettimeofday(&xtime);
 
 	setup_irq(TIMER_IRQ, &irq0);
 
-	if (MACH_DREAMCAST)
-		timer_freq = 50*1000*1000/4;
-	else
-		timer_freq = get_timer_frequency();
+	timer_freq = get_timer_frequency();
 
 	module_clock = timer_freq * 4;

===================================================================
/* arch/sh/kernel/rtc-aica.c
 *
 * Dreamcast AICA RTC routines.
 *
 * Copyright (c) 2001 M. R. Brown <mr...@0x...>
 *
 * Released under the terms of the GNU GPL v2.0.
 *
 */

#include <linux/time.h>

#include <asm/io.h>

/* The AICA RTC has an Epoch of 1/1/1950, so we must subtract 20 years (in
   seconds to get the standard Unix Epoch when getting the time, and add 20
   years when setting the time. */
#define TWENTY_YEARS ((20 * 365LU + 5) * 86400)

/* The AICA RTC is represented by a 32-bit seconds counter stored in 2 16-bit
   registers.*/
#define AICA_RTC_SECS_H		0xa0710000
#define AICA_RTC_SECS_L		0xa0710004

/**
 * aica_rtc_gettimeofday - Get the time from the AICA RTC
 * @tv: pointer to resulting timeval
 *
 * Grabs the current RTC seconds counter and adjusts it to the Unix Epoch.
 */
void aica_rtc_gettimeofday(struct timeval *tv) {
	unsigned long val1, val2;

	do {
		val1 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);

		val2 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
	} while (val1 != val2);

	tv->tv_sec = val1 - TWENTY_YEARS;

	/* Can't get microseconds with just a seconds counter. */
	tv->tv_usec = 0;
}

/**
 * aica_rtc_settimeofday - Set the AICA RTC to the current time
 * @tv: contains the timeval to set
 *
 * Adjusts the given @tv to the AICA Epoch and sets the RTC seconds counter.
 */
int aica_rtc_settimeofday(const struct timeval *tv) {
	unsigned long val1, val2;
	unsigned long secs = tv->tv_sec + TWENTY_YEARS;

	do {
		ctrl_outl((secs & 0xffff0000) >> 16, AICA_RTC_SECS_H);
		ctrl_outl((secs & 0xffff), AICA_RTC_SECS_L);

		val1 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);

		val2 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
	} while (val1 != val2);

	return 0;
}

[linuxsh-dev] Dreamcast RTC routines

[M. R. B. <mr...@su...>]

Here's preliminary support for the Dreamcast AICA RTC registers - it adds
the appropiate calls to the machvec which allows the timer frequency and
RTC query stuff to work as intended.

I'll be writing mc146818rtc stuff in a bit.

M. R.

2000-08-31  M. R. Brown <mr...@0x...>

	* arch/sh/kernel/Makefile: Add dependency for rtc-aica.o for
	CONFIG_SH_DREAMCAST.
	* arch/sh/kernel/mach_dc.c: Add prototypes and pointers for the AICA
	RTC routines to the machvec.
	* arch/sh/kernel/time.c (time_init): Remove checks for
	MACH_DREAMCAST as we can just use the RTC routines defined in the
	machvec.
	* arch/sh/kernel/rtc-aica.c: New file.

Index: Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- Makefile	2001/08/24 12:38:19	1.30
+++ Makefile	2001/09/01 06:08:03
@@ -74,7 +74,7 @@
 obj-$(CONFIG_HD64465)		+= setup_hd64465.o io_hd64465.o hd64465_gpio.o
 obj-$(CONFIG_SH_DMIDA)		+= mach_dmida.o
 obj-$(CONFIG_SH_EC3104)         += setup_ec3104.o io_ec3104.o mach_ec3104.o
-obj-$(CONFIG_SH_DREAMCAST)	+= mach_dc.o setup_dc.o io_dc.o
+obj-$(CONFIG_SH_DREAMCAST)	+= mach_dc.o setup_dc.o io_dc.o rtc-aica.o
 
 ifeq ($(CONFIG_SH_GENERIC),y)
 obj-y		+= $(machine-specific-objs)
Index: mach_dc.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_dc.c,v
retrieving revision 1.4
diff -u -r1.4 mach_dc.c
--- mach_dc.c	2001/05/24 05:09:16	1.4
+++ mach_dc.c	2001/09/01 06:08:03
@@ -1,10 +1,11 @@
 /*
- *	$Id: mach_dc.c,v 1.4 2001/05/24 05:09:16 mrbrown Exp $
+ *	$Id: mach_dc.c,v 1.2 2001/09/01 04:45:08 mrbrown Exp $
  *	SEGA Dreamcast machine vector
  */
 
 #include <linux/config.h>
 #include <linux/init.h>
+#include <linux/time.h>
 
 #include <asm/machvec.h>
 #include <asm/machvec_init.h>
@@ -16,6 +17,10 @@
 void __init setup_dreamcast(void);
 void __init dreamcast_pcibios_init(void);
 
+/* Custom Dreamcast RTC routines */
+void aica_rtc_gettimeofday(struct timeval *tv);
+int aica_rtc_settimeofday(const struct timeval *tv);
+
 /*
  * The Machine Vector
  */
@@ -59,6 +64,9 @@
 	mv_init_arch:		setup_dreamcast,
 	mv_isa_port2addr:	dreamcast_isa_port2addr,
 	mv_irq_demux:		systemasic_irq_demux,
+
+	mv_rtc_gettimeofday:	aica_rtc_gettimeofday,
+	mv_rtc_settimeofday:	aica_rtc_settimeofday,
 
 	mv_hw_dreamcast:	1,
 };
Index: time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.29
diff -u -r1.29 time.c
--- time.c	2001/07/23 10:43:42	1.29
+++ time.c	2001/09/01 06:08:03
@@ -1,4 +1,4 @@
-/* $Id: time.c,v 1.29 2001/07/23 10:43:42 gniibe Exp $
+/* $Id: time.c,v 1.2 2001/09/01 04:45:48 mrbrown Exp $
  *
  *  linux/arch/sh/kernel/time.c
  *
@@ -359,17 +359,11 @@
 #endif
 #endif
 
-	if (MACH_DREAMCAST)
-		xtime.tv_sec = xtime.tv_usec = 0;
-	else
-		rtc_gettimeofday(&xtime);
+	rtc_gettimeofday(&xtime);
 
 	setup_irq(TIMER_IRQ, &irq0);
 
-	if (MACH_DREAMCAST)
-		timer_freq = 50*1000*1000/4;
-	else
-		timer_freq = get_timer_frequency();
+	timer_freq = get_timer_frequency();
 
 	module_clock = timer_freq * 4;

===================================================================
/* arch/sh/kernel/rtc-aica.c
 *
 * Dreamcast AICA RTC routines.
 *
 * Copyright (c) 2001 M. R. Brown <mr...@0x...>
 *
 * Released under the terms of the GNU GPL v2.0.
 *
 */

#include <linux/time.h>

#include <asm/io.h>

/* The AICA RTC has an Epoch of 1/1/1950, so we must subtract 20 years (in
   seconds to get the standard Unix Epoch when getting the time, and add 20
   years when setting the time. */
#define TWENTY_YEARS ((20 * 365LU + 5) * 86400)

/* The AICA RTC is represented by a 32-bit seconds counter stored in 2 16-bit
   registers.*/
#define AICA_RTC_SECS_H		0xa0710000
#define AICA_RTC_SECS_L		0xa0710004

/**
 * aica_rtc_gettimeofday - Get the time from the AICA RTC
 * @tv: pointer to resulting timeval
 *
 * Grabs the current RTC seconds counter and adjusts it to the Unix Epoch.
 */
void aica_rtc_gettimeofday(struct timeval *tv) {
	unsigned long val1, val2;

	do {
		val1 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);

		val2 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
	} while (val1 != val2);

	tv->tv_sec = val1 - TWENTY_YEARS;

	/* Can't get microseconds with just a seconds counter. */
	tv->tv_usec = 0;
}

/**
 * aica_rtc_settimeofday - Set the AICA RTC to the current time
 * @tv: contains the timeval to set
 *
 * Adjusts the given @tv to the AICA Epoch and sets the RTC seconds counter.
 */
int aica_rtc_settimeofday(const struct timeval *tv) {
	unsigned long val1, val2;
	unsigned long secs = tv->tv_sec + TWENTY_YEARS;

	do {
		ctrl_outl((secs & 0xffff0000) >> 16, AICA_RTC_SECS_H);
		ctrl_outl((secs & 0xffff), AICA_RTC_SECS_L);

		val1 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);

		val2 = ((ctrl_inl(AICA_RTC_SECS_H) & 0xffff) << 16) |
			(ctrl_inl(AICA_RTC_SECS_L) & 0xffff);
	} while (val1 != val2);

	return 0;
}

[linuxsh-dev] Problem w/SR macros?

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

I've been having a problem with recent kernels, apparently due
to the definition of include/asm-sh/system.h:__save_and_cli();
looks like "volatile" was inadvertently left out, resulting in the
occasional demise of the cli due to compiler optimization...

[In my case, the netif_rx() reference to __cpu_raise_softirq()
expanded to an unprotected set_bit(): a timer interrupt right at
that point scheduled the tasklet but lost the softirq; timer_bh
would then never run until some other interrupt caused another
HI_SOFTIRQ... but I suspect other things could go wrong too.]

Any reason NOT to commit the following patch?  (It's really
just adding volatile; the rest is whitespace ;-)

--- system.h~ Tue Jul 31 03:12:05 2001
+++ system.h Thu Aug 30 12:11:54 2001
@@ -136,13 +136,15 @@
 {
  unsigned long flags, __dummy;

- __asm__("stc sr, %1\n\t"
-  "mov %1, %0\n\t"
-  "or #0xf0, %0\n\t"
-  "ldc %0, sr\n\t"
-  "mov %1, %0\n\t"
-  "and #0xf0, %0"
-  : "=&z" (flags), "=&r" (__dummy) :/**/: "memory" );
+ __asm__ __volatile__ ("stc sr, %1\n\t"
+         "mov %1, %0\n\t"
+         "or #0xf0, %0\n\t"
+         "ldc %0, sr\n\t"
+         "mov %1, %0\n\t"
+         "and #0xf0, %0"
+         : "=&z" (flags), "=&r" (__dummy)
+         :/**/
+         : "memory");
  return flags;
 }

[linuxsh-dev] missing operations in atomic.h

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

There seem to be a couple operations missing in atomic.h.  The following is
a patch to add the 'atomic_add_and_test' and 'atomic_inc_and_test' to the
asm/atomic.h header.

Index: atomic.h
===================================================================
RCS file: /home/CVS-ext/mgate/software/core/kernel/include/asm-sh/atomic.h,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -u -r1.1.1.2 -r1.2
--- atomic.h	2001/07/23 17:52:34	1.1.1.2
+++ atomic.h	2001/08/28 03:15:36	1.2
@@ -71,6 +71,8 @@

 #define atomic_sub_and_test(i,v) (atomic_sub_return((i), (v)) == 0)
 #define atomic_dec_and_test(v) (atomic_sub_return(1, (v)) == 0)
+#define atomic_add_and_test(i,v) (atomic_add_return((i), (v)) == 0)
+#define atomic_inc_and_test(v) (atomic_add_return(1, (v)) == 0)

 #define atomic_inc(v) atomic_add(1,(v))
 #define atomic_dec(v) atomic_sub(1,(v))

[linuxsh-dev] stable SH4 environment

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

NIIBE Yutaka <gn...@m1...> wrote:
>> 4) what is an approximate timeframe for getting binutils and gcc patches
>> for LinuxSH merged with the mainline GNU trees? My work with Linux
>> on the PPC405 has led me to think that this should be a _really_ high
>> priority for all embedded forks of Linux/GNU tools. If my employer
>> allows, I could be able to spend some time assisting in what ever way
>> possible.
>> 
>> Thanks! I'm looking forward to working with all of you again.
> 
> Yes, I think so too.  I'm not sure for the timeframe, I expects Kaz
> comments for that.  I explain the current status here.

I also have no clear plan. Anyway, almost essential changes are already
included in mainline except a few patches. Some unsended patches need
more tests, for example, like -mno-fdiv-divsi patch.

> This two weeks, I've tried to provide GNU/SH tool-chain for Debian.
> I've done some work based on binutils-2.11.2 and GCC 3.0.1.
> 
> I think that binutils is ready for use.  I sent diffs to Takeshi for
> comments.  I expect new binutils-sh-linux Debian package comes soon by
> Takeshi.  And I sent the needed diff to Kaz for comments, then, he
> tried it to current CVS version.  Next comes, send them to mainline
> binutils development.

I'm putting patches for the current CVS as

  http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/src-cvs-010822.diff
  http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/src-cvs-010822-2add.tar.gz

I'm happy if you have time to test this.

> For GCC, I think that it's not ready.  Major concern is the definition
> of multilibbed environment.  I built my own Debian gcc-sh-linux 3.0.1
> package.  I'm now using this for my experiment, and try to build some
> sort of Debian SH-4 distribution with this 3.0.1.  While I'm doing
> this week, I encountered issues of name of libgcc shared library, 
> still not solved.

I think so. Shared libgcc of 3.x is a drastic change and is a kind of
"no return".

	kaz

[linuxsh-dev] stable SH4 environment

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

NIIBE Yutaka wrote:
 > I've put my testing version to:
 > 	ftp://ftp.m17n.org/pub/linux-sh/testing/
 > 
 >  Sorry, this time, it's only for Debian.  The patch for GCC 3.0.1
 > includes -mno-fdiv-divsi switch.
 > 
 > I'm currently building glibc 2.2.4 with this tool-chain.

The version I put yesterday was bad.  I uploaded good version now.
With it, I've tested to compile glibc 2.2.4 for all four configurations
(sh3, sh4, sh4eb, sh3eb) and kernel for DC.

Here's the patch for new tool chain.  Well, I'd like to commit this
change, say, a month later, after we test GCC 3.0.

	* arch/sh/Makefile (CFLAGS): Use -mno-fdiv-divsi.  Don't use
	-m4-nofpu.

Index: arch/sh/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- arch/sh/Makefile	2001/07/28 04:02:00	1.20
+++ arch/sh/Makefile	2001/08/24 22:22:23
@@ -46,8 +46,8 @@
 AFLAGS		+= -m3
 endif
 ifdef CONFIG_CPU_SH4
-CFLAGS		+= -m4-nofpu
-AFLAGS		+= -m4-nofpu
+CFLAGS		+= -m4 -mno-fdiv-divsi
+AFLAGS		+= -m4 -mno-fdiv-divsi
 endif
 
 #
-- 

[linuxsh-dev] Fix for sh3 cache flush code.

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

Oops. 

 $ cvs diff -w ChangeLog arch/sh/mm/cache-sh3.c
Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.334
diff -u -w -r1.334 ChangeLog
--- ChangeLog	2001/08/24 12:38:19	1.334
+++ ChangeLog	2001/08/24 14:41:18
@@ -1,5 +1,8 @@
 2001-08-24  David Woodhouse  <dw...@in...>
 
+	* arch/sh/mm/cache-sh3.c: We were missing a loop over the ways in
+	__flush_wback_region(). Also disable interrupts between reading
+	an entry and writing it back modified.
 	* arch/sh/kernel/pcibios.c: Generic versions of five pcibios_xxx()
 	functions which can be shared between platforms.
 	* arch/sh/kernel/pci_st40.c: Use $1.
Index: arch/sh/mm/cache-sh3.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh3.c,v
retrieving revision 1.4
diff -u -w -r1.4 cache-sh3.c
--- arch/sh/mm/cache-sh3.c	2001/08/10 14:13:13	1.4
+++ arch/sh/mm/cache-sh3.c	2001/08/24 14:41:18
@@ -156,24 +156,30 @@
 {
 	unsigned long v, j;
 	unsigned long begin, end;
+	unsigned long flags;
 
 	begin = (unsigned long)start & ~(L1_CACHE_BYTES-1);
 	end = ((unsigned long)start + size + L1_CACHE_BYTES-1)
 		& ~(L1_CACHE_BYTES-1);
 
 	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
+		for (j=0; j<CACHE_OC_NUM_WAYS; j++) {
 		unsigned long data, addr, p;
 
 		p = __pa(v);
 		addr = CACHE_OC_ADDRESS_ARRAY|(j<<CACHE_OC_WAY_SHIFT)|
 			(v&CACHE_OC_ENTRY_MASK);
+			save_and_cli(flags);
 		data = ctrl_inl(addr);
 		
 		if ((data & CACHE_PHYSADDR_MASK) ==
 		    (p & CACHE_PHYSADDR_MASK)) {
 			data &= ~CACHE_UPDATED;
 			ctrl_outl(data, addr);
+				restore_flags(flags);
 			break;
+			}
+			restore_flags(flags);
 		}
 	}
 }

--
dwmw2

[linuxsh-dev] stable SH4 environment

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

NIIBE Yutaka wrote:
 > This two weeks, I've tried to provide GNU/SH tool-chain for Debian.
 > I've done some work based on binutils-2.11.2 and GCC 3.0.1.

I've put my testing version to:
	ftp://ftp.m17n.org/pub/linux-sh/testing/

 Sorry, this time, it's only for Debian.  The patch for GCC 3.0.1
includes -mno-fdiv-divsi switch.

I'm currently building glibc 2.2.4 with this tool-chain.
--