linuxsh-dev

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

[Paul M. <pm...@MV...>]

Hello,

Maybe it's just me, but I can't think of any good reason why arch/sh/Makefi=
le
should be overriding the toplevel CROSS_COMPILE outright if it's already be=
en
set..

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

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Index: ChangeLog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.343
diff -u -r1.343 ChangeLog
--- ChangeLog	2001/09/15 04:41:45	1.343
+++ ChangeLog	2001/09/15 20:50:29
@@ -1,3 +1,8 @@
+2001-09-15  Paul Mundt  <le...@ch...>
+
+	* arch/sh/Makefile: Add check to see if CROSS_COMPILE has been
+	set before overriding it.
+=09
 2001-09-13  NIIBE Yutaka  <gn...@m1...>
=20
 	* arch/sh/kernel/sys_sh.c (arch_get_unmapped_area): Don't
Index: arch/sh/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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/09/15 20:50:47
@@ -29,9 +29,9 @@
 LDFLAGS		:=3D -EB
 endif
=20
-# ifdef CONFIG_CROSSCOMPILE
+ifndef CROSS_COMPILE
 CROSS_COMPILE  =3D $(tool_prefix)
-# endif
+endif
=20
 LD	=3D$(CROSS_COMPILE)ld $(LDFLAGS)
 OBJCOPY=3D$(CROSS_COMPILE)objcopy -O binary -R .note -R .comment -R .stab =
-R .stabstr -S

RE: [linuxsh-dev] help

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

http://linuxsh.sourceforge.net/docs/building-source.php3

Everything is on the homepage of LinuxSH,
http://linuxsh.sourceforge.net.

Bao


> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of vijay
> Sent: Thursday, September 13, 2001 2:37 AM
> To: NIIBE Yutaka; Ulrich Drepper; Bao C. Ha;
> lin...@li...; lin...@m1...
> Subject: [linuxsh-dev] help
> 
> 
> hi all,
> 
> I understand that this is newbie question.
> still i ahve to ask as i am really stuck up..
> can any body give me the links to documnets available..
> 
> about the infomation of linuxSh...
> or any info..
> from whre to start.. to understand the linux kernel.. and 
> configuring it
> accoording to
> sh  target..
> (i am familiar with sh processors.. and linux as a end user..)
> regards,
> vijay
> 
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 

[linuxsh-dev] [PATCH] SH3/4 Watchdog Support

[Paul M. <pm...@MV...>]

Hello,

Here's preliminary support for the watchdog devices found in the sh3 and sh=
4.
It's loosely based off of the NetBSD driver.

Adding the menu to arch/sh/config.in seems like somewhat of a hack.. but it
was the only solution given that all that stuff is hardcoded directly in the
drivers/char/Config.in. (WDT stuff should be moved to drivers/char/wdt IMO).

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.


Index: ChangeLog
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.341
diff -u -r1.341 ChangeLog
--- ChangeLog	2001/09/11 02:30:41	1.341
+++ ChangeLog	2001/09/13 10:40:48
@@ -1,3 +1,10 @@
+2001-09-13  Paul Mundt  <le...@ch...>
+
+	* Documentation/Configure.help: Add CONFIG_SH_WDT description.
+	* arch/sh/config.in: Add watchdog card menu, and watchdog driver.
+	* drivers/char/Makefile: Add CONFIG_SH_WDT support.
+	* drivers/char/shwdt.c: New file.
+
 2001-09-11  NIIBE Yutaka  <gn...@m1...>
=20
 	* include/asm-sh/softirq.h (__cpu_raise_softirq): Removed.
Index: Documentation/Configure.help
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/Documentation/Configure.help,v
retrieving revision 1.78
diff -u -r1.78 Configure.help
--- Documentation/Configure.help	2001/09/11 02:30:41	1.78
+++ Documentation/Configure.help	2001/09/13 10:31:22
@@ -14732,6 +14732,17 @@
   The module is called machzwd.o. If you want to compile it as a module,
   say M here and read Documentation/modules.txt.
=20
+SuperH 3/4 Watchdog
+CONFIG_SH_WDT
+  This driver adds watchdog support for the integrated watchdog in the
+  SuperH 3 and 4 processors. If you have one of these processors, say Y,
+  otherwise say N.
+
+  This driver is also available as a module ( =3D code which can be
+  inserted in and removed from the running kernel whenever you want).
+  The module is called shwdt.o. If you want to compile it as a module,
+  say M here and read Documentation/modules.txt.
+	     =20
 Toshiba Laptop support
 CONFIG_TOSHIBA
   This adds a driver to safely access the System Management Mode
Index: arch/sh/config.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.57
diff -u -r1.57 config.in
--- arch/sh/config.in	2001/08/23 16:36:40	1.57
+++ arch/sh/config.in	2001/09/13 10:31:34
@@ -326,6 +326,16 @@
    dep_tristate 'Support for user-space parallel port device drivers' CONF=
IG_PPDEV $CONFIG_PARPORT
 fi
 bool 'PS/2 mouse (aka "auxiliary device") support' CONFIG_PSMOUSE
+
+mainmenu_option next_comment
+comment 'Watchdog Cards'
+bool 'Watchdog Timer Support' CONFIG_WATCHDOG
+if [ "$CONFIG_WATCHDOG" !=3D "n" ]; then
+   bool '  Disable watchdog shutdown on close' CONFIG_WATCHDOG_NOWAYOUT
+   dep_tristate '  SH 3/4 Watchdog' CONFIG_SH_WDT $CONFIG_SUPERH
+fi
+endmenu
+
 tristate 'Enhanced Real Time Clock Support' CONFIG_RTC
 if [ "$CONFIG_HOTPLUG" =3D "y" -a "$CONFIG_PCMCIA" !=3D "n" ]; then
    source drivers/char/pcmcia/Config.in
Index: drivers/char/Makefile
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/linuxsh/kernel/drivers/char/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- drivers/char/Makefile	2001/09/06 04:01:39	1.26
+++ drivers/char/Makefile	2001/09/13 10:31:42
@@ -215,6 +215,7 @@
 obj-$(CONFIG_977_WATCHDOG) +=3D wdt977.o
 obj-$(CONFIG_I810_TCO) +=3D i810-tco.o
 obj-$(CONFIG_MACHZ_WDT) +=3D machzwd.o
+obj-$(CONFIG_SH_WDT) +=3D shwdt.o
 obj-$(CONFIG_SOFT_WATCHDOG) +=3D softdog.o
=20
=20
--- drivers/char/shwdt.c.orig	Thu Sep 13 03:34:58 2001
+++ drivers/char/shwdt.c	Thu Sep 13 03:16:03 2001
@@ -0,0 +1,365 @@
+/*
+ * drivers/char/shwdt.c
+ *
+ * Watchdog driver for integrated watchdog in the SuperH 3/4 processors.
+ *
+ * Copyright (C) 2001 Paul Mundt <le...@ch...>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/miscdevice.h>
+#include <linux/watchdog.h>
+#include <linux/reboot.h>
+#include <linux/notifier.h>
+#include <linux/smp_lock.h>
+#include <linux/ioport.h>
+
+#include <asm/io.h>
+#include <asm/uaccess.h>
+
+#if defined(CONFIG_CPU_SH4)
+  #define WTCNT		0xffc00008
+  #define WTCSR		0xffc0000c
+#elif defined(CONFIG_CPU_SH3)
+  #define WTCNT		0xffffff84
+  #define WTCSR		0xffffff86
+#else
+  #error "Can't use SH 3/4 watchdog on non-SH 3/4 processor."
+#endif
+
+#define WTCNT_HIGH	0x5a00
+#define WTCSR_HIGH	0xa500
+
+#define WTCSR_TME	0x80
+#define WTCSR_WT	0x40
+#define WTCSR_RSTS	0x20
+#define WTCSR_WOVF	0x10
+#define WTCSR_IOVF	0x08
+#define WTCSR_CKS2	0x04
+#define WTCSR_CKS1	0x02
+#define WTCSR_CKS0	0x01
+
+#define WTCSR_CKS	0x07
+#define WTCSR_CKS_1	0x00
+#define WTCSR_CKS_4	0x01
+#define WTCSR_CKS_16	0x02
+#define WTCSR_CKS_32	0x03
+#define WTCSR_CKS_64	0x04
+#define WTCSR_CKS_256	0x05
+#define WTCSR_CKS_1024	0x06
+#define WTCSR_CKS_4096	0x07
+
+static int sh_is_open =3D 0;
+static struct watchdog_info sh_wdt_info;
+
+/**
+ *	sh_wdt_write_cnt - Write to Counter
+ *
+ *	@val: Value to write
+ *
+ *	Writes the given value @val to the lower byte of the timer counter.
+ *	The upper byte is set manually on each write.
+ */
+static void sh_wdt_write_cnt(__u8 val)
+{
+	ctrl_outw(WTCNT_HIGH | (__u16)val, WTCNT);
+}
+
+/**
+ * 	sh_wdt_write_csr - Write to Control/Status Register
+ *
+ * 	@val: Value to write
+ *
+ * 	Writes the given value @val to the lower byte of the control/status
+ * 	register. The upper byte is set manually on each write.
+ */
+static void sh_wdt_write_csr(__u8 val)
+{
+	ctrl_outw(WTCSR_HIGH | (__u16)val, WTCSR);
+}
+
+/**
+ * 	sh_wdt_start - Start the Watchdog
+ *
+ * 	Starts the watchdog.
+ */
+static void sh_wdt_start(void)
+{
+	sh_wdt_write_csr(WTCSR_WT | WTCSR_CKS_4096);
+	sh_wdt_write_cnt(0);
+	sh_wdt_write_csr((ctrl_inb(WTCSR) | WTCSR_TME));
+}
+
+/**
+ * 	sh_wdt_stop - Stop the Watchdog
+ *
+ * 	Stops the watchdog.
+ */
+static void sh_wdt_stop(void)
+{
+	sh_wdt_write_csr((ctrl_inb(WTCSR) & ~WTCSR_TME));
+}
+
+/**
+ * 	sh_wdt_ping - Ping the Watchdog
+ *
+ *	@data: Unused
+ *
+ * 	Clears overflow bit, resets timer counter.
+ */
+static void sh_wdt_ping(unsigned long data)
+{
+	sh_wdt_write_csr((ctrl_inb(WTCSR) & ~WTCSR_IOVF));
+	sh_wdt_write_cnt(0);
+}
+
+/**
+ * 	sh_wdt_open - Open the Device
+ *
+ * 	@inode: inode of device
+ * 	@file: file handle of device
+ *
+ * 	Watchdog device is opened and started.
+ */
+static int sh_wdt_open(struct inode *inode, struct file *file)
+{
+	switch (MINOR(inode->i_rdev)) {
+		case WATCHDOG_MINOR:
+			if (sh_is_open) {
+				return -EBUSY;
+			}
+
+			sh_is_open =3D 1;
+			sh_wdt_start();
+
+			return 0;
+		default:
+			return -ENODEV;
+	}
+
+	return 0;
+}
+
+/**
+ * 	sh_wdt_close - Close the Device
+ *
+ * 	@inode: inode of device
+ * 	@file: file handle of device
+ *
+ * 	Watchdog device is closed and stopped.
+ */
+static int sh_wdt_close(struct inode *inode, struct file *file)
+{
+	lock_kernel();
+=09
+	if (MINOR(inode->i_rdev) =3D=3D WATCHDOG_MINOR) {
+#ifndef CONFIG_WATCHDOG_NOWAYOUT
+		sh_wdt_stop();
+#endif
+		sh_is_open =3D 0;
+	}
+=09
+	unlock_kernel();
+
+	return 0;
+}
+
+/**
+ * 	sh_wdt_read - Read from Device
+ *
+ * 	@file: file handle of device
+ * 	@char: buffer to write to
+ * 	@count: length of buffer
+ * 	@ppos: offset
+ *
+ * 	Unsupported.
+ */
+static ssize_t sh_wdt_read(struct file *file, char *buf,
+			   size_t count, loff_t *ppos)
+{
+	return -EINVAL;
+}
+
+/**
+ * 	sh_wdt_write - Write to Device
+ *
+ * 	@file: file handle of device
+ * 	@char: buffer to write
+ * 	@count: length of buffer
+ * 	@ppos: offset
+ *
+ * 	Pings the watchdog on write.
+ */
+static ssize_t sh_wdt_write(struct file *file, const char *buf,
+			    size_t count, loff_t *ppos)
+{
+	/* Can't seek (pwrite) on this device */
+	if (ppos !=3D &file->f_pos)
+		return -ESPIPE;
+
+	if (count) {
+		sh_wdt_ping(0);
+		return 1;
+	}
+
+	return 0;
+}
+
+/**
+ * 	sh_wdt_ioctl - Query Device
+ *
+ * 	@inode: inode of device
+ * 	@file: file handle of device
+ * 	@cmd: watchdog command
+ * 	@arg: argument
+ *
+ * 	Query basic information from the device or ping it, as outlined by the
+ * 	watchdog API.
+ */
+static int sh_wdt_ioctl(struct inode *inode, struct file *file,
+			unsigned int cmd, unsigned long arg)
+{
+	switch (cmd) {
+		case WDIOC_GETSUPPORT:
+			if (copy_to_user((struct watchdog_info *)arg,
+					  &sh_wdt_info,
+					  sizeof(sh_wdt_info))) {
+				return -EFAULT;
+			}
+		=09
+			break;
+		case WDIOC_GETSTATUS:
+			if (copy_to_user((int *)arg,
+					 &sh_is_open,
+					 sizeof(int))) {
+				return -EFAULT;
+			}
+
+			break;
+		case WDIOC_KEEPALIVE:
+			sh_wdt_ping(0);
+		=09
+			break;
+		default:
+			return -ENOTTY;
+	}
+
+	return 0;
+}
+
+/**
+ * 	sh_wdt_notify_sys - Notifier Handler
+ * =09
+ * 	@this: notifier block
+ * 	@code: notifier event
+ * 	@unused: unused
+ *
+ * 	Handles specific events, such as turning off the watchdog during a
+ * 	shutdown event.
+ */
+static int sh_wdt_notify_sys(struct notifier_block *this,
+			     unsigned long code, void *unused)
+{
+	if (code =3D=3D SYS_DOWN || SYS_HALT) {
+		sh_wdt_stop();
+	}
+
+	return NOTIFY_DONE;
+}
+
+static struct file_operations sh_wdt_fops =3D {
+	owner:		THIS_MODULE,
+	read:		sh_wdt_read,
+	write:		sh_wdt_write,
+	ioctl:		sh_wdt_ioctl,
+	open:		sh_wdt_open,
+	release:	sh_wdt_close,
+};
+
+static struct watchdog_info sh_wdt_info =3D {
+	WDIOF_KEEPALIVEPING,
+	1,
+	"SH WDT",
+};
+
+static struct notifier_block sh_wdt_notifier =3D {
+	sh_wdt_notify_sys,
+	NULL,
+	0
+};
+
+static struct miscdevice sh_wdt_miscdev =3D {
+	WATCHDOG_MINOR,
+	"watchdog",
+	&sh_wdt_fops,
+};
+
+/**
+ * 	sh_wdt_init - Initialize module
+ *
+ * 	Registers the device and notifier handler. Actual device
+ * 	initialization is handled by sh_wdt_open().
+ */
+static int __init sh_wdt_init(void)
+{
+	if (misc_register(&sh_wdt_miscdev)) {
+		printk(KERN_ERR "shwdt: Can't register misc device\n");
+		return -EINVAL;
+	}
+
+	if (!request_region(WTCNT, 1, "shwdt")) {
+		printk(KERN_ERR "shwdt: Can't request WTCNT region\n");
+		misc_deregister(&sh_wdt_miscdev);
+		return -ENXIO;
+	}
+
+	if (!request_region(WTCSR, 1, "shwdt")) {
+		printk(KERN_ERR "shwdt: Can't request WTCSR region\n");
+		release_region(WTCNT, 1);
+		misc_deregister(&sh_wdt_miscdev);
+		return -ENXIO;
+	}
+
+	if (register_reboot_notifier(&sh_wdt_notifier)) {
+		printk(KERN_ERR "shwdt: Can't register reboot notifier\n");
+		release_region(WTCSR, 1);
+		release_region(WTCNT, 1);
+		misc_deregister(&sh_wdt_miscdev);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
+ * 	sh_wdt_exit - Deinitialize module
+ *
+ * 	Unregisters the device and notifier handler. Actual device
+ * 	deinitialization is handled by sh_wdt_close().
+ */
+static void __exit sh_wdt_exit(void)
+{
+	unregister_reboot_notifier(&sh_wdt_notifier);
+	release_region(WTCSR, 1);
+	release_region(WTCNT, 1);
+	misc_deregister(&sh_wdt_miscdev);
+}
+
+EXPORT_NO_SYMBOLS;
+
+MODULE_AUTHOR("Paul Mundt <le...@ch...>");
+MODULE_DESCRIPTION("SH 3/4 watchdog driver");
+MODULE_LICENSE("GPL");
+
+module_init(sh_wdt_init);
+module_exit(sh_wdt_exit);
+

[linuxsh-dev] help

[vijay <vi...@kp...>]

hi all,

I understand that this is newbie question.
still i ahve to ask as i am really stuck up..
can any body give me the links to documnets available..

about the infomation of linuxSh...
or any info..
from whre to start.. to understand the linux kernel.. and configuring it
accoording to
sh  target..
(i am familiar with sh processors.. and linux as a end user..)
regards,
vijay

Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

We need to implement
	MAP_SHARED: COLOUR_ALIGN
	MAP_PRIVATE: PAGE_ALIGN (Don't COLOUR_ALIGN)
	Others: don't care

I think that it's good to set default to COLOUR_ALIGN, as cache
works well.  Here's a patch.

	* arch/sh/kernel/sys_sh.c (arch_get_unmapped_area): Don't
	COLOUR_ALIGN when it comes with MAP_PRIVATE.

Index: arch/sh/kernel/sys_sh.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/sys_sh.c,v
retrieving revision 1.7
diff -u -r1.7 sys_sh.c
--- arch/sh/kernel/sys_sh.c	2001/08/03 23:50:59	1.7
+++ arch/sh/kernel/sys_sh.c	2001/09/13 01:11:11
@@ -68,7 +68,10 @@
 	if (!addr)
 		addr = TASK_UNMAPPED_BASE;
 
-	addr = COLOUR_ALIGN(addr);
+	if (flags & MAP_PRIVATE)
+		addr = PAGE_ALIGN(addr);
+	else
+		addr = COLOUR_ALIGN(addr);
 
 	for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
 		/* At this point:  (!vma || addr < vma->vm_end). */
@@ -77,7 +80,8 @@
 		if (!vma || addr + len <= vma->vm_start)
 			return addr;
 		addr = vma->vm_end;
-		addr = COLOUR_ALIGN(addr);
+		if (!(flags & MAP_PRIVATE))
+			addr = COLOUR_ALIGN(addr);
 	}
 }
 #endif
-- 

RE: [linux-sh:01934] Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

Hi NIIBE,

Thank you.  We will try them.

Hi Ulrich,

Sorry to get you into this.  It looks like we are getting
a satisfactory resolution of consistent kernel behaviors
across platforms now.

Appreciate everybody's help and insight/suggestion.

Regards.
Bao

> -----Original Message-----
> From: NIIBE Yutaka [mailto:gn...@m1...]
> Sent: Tuesday, September 11, 2001 5:42 PM
> To: Ulrich Drepper; Bao C. Ha
> Cc: lin...@li...; lin...@m1...
> Subject: [linux-sh:01934] Re: [linuxsh-dev] Different 
> old_mmap behavior
> in 2.4.5 and 2.4.8
> 
> 
> My bad.
> 
> Bao, please try version 1.6 (former version) of 
> arch/sh/kernel/sys_sh.c.
> 
> It did checks if the page is shared or not.  It does COLOUR_ALIGN the
> address, only if it's shared.
> 
> At that time, I did find always COLOUR_ALIGN makes the performance
> better (because of good cache hit), and didn't know it breaks
> semantics and some applications.
> 
> I'll revert the change of following:
> 
> 2001-08-03  NIIBE Yutaka  <gn...@m1...>
> 
> 	* arch/sh/kernel/sys_sh.c (arch_get_unmapped_area): Always align
> 	to 16KB.
> -- 
> 

[linuxsh-dev] stable SH4 environment

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

For those weeks, I've been experimenting (finding) stable tool chain.

I've put my bootstrapping of Debian SuperH at:
	ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010911/

This includes sh3,sh3eb,sh4,sh4eb.

Most is specific to Debian.

The patch I've used for GCC is at:
ftp://ftp.m17n.org/pub/linux-sh/testing/debian-010911/STEP-1.4/sh3/gcc-3.0-3.0.2ds0/debian/patches/superh.dpatch

Cross compiler works well.

Even with reverted sys_sh.c, libpthread.so doesn't work well, investigating.
-- 

Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

My bad.

Bao, please try version 1.6 (former version) of arch/sh/kernel/sys_sh.c.

It did checks if the page is shared or not.  It does COLOUR_ALIGN the
address, only if it's shared.

At that time, I did find always COLOUR_ALIGN makes the performance
better (because of good cache hit), and didn't know it breaks
semantics and some applications.

I'll revert the change of following:

2001-08-03  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/kernel/sys_sh.c (arch_get_unmapped_area): Always align
	to 16KB.
-- 

Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

dr...@re... said:
>  Then fix the kernel.  The change is necessary and correct.

I suppose it is feasible for the kernel to accommodate MAP_ANONYMOUS mmap at
the 'wrong' page addresses. Whether it _should_ do that or not sort of 
depends on how good the reasons are for not specifying MAP_FIXED in 
libpthread when you obviously seem to have meant it that way.

I think a combination of mmap(MAP_ANONYMOUS|MAP_SHARED); fork();
mremap(MAP_FIXED) may still get the SH4 to screw up, but I think that was
the case anyway. Mremap seems to be fundamentally broken in that respect - it
doesn't have the same hooks (arch_get_unmapped_area()) that mmap() has to
allow the arch code to vet the addresses use.

I'll leave that one as an exercise for the reader.

Index: arch/sh/kernel/sys_sh.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/sys_sh.c,v
retrieving revision 1.7
diff -u -r1.7 sys_sh.c
--- arch/sh/kernel/sys_sh.c	2001/08/03 23:50:59	1.7
+++ arch/sh/kernel/sys_sh.c	2001/09/11 21:39:00
@@ -68,7 +68,9 @@
 	if (!addr)
 		addr = TASK_UNMAPPED_BASE;
 
-	addr = COLOUR_ALIGN(addr);
+	/* We don't need to do the cache colouring for anonymous pages */
+	if (filp)
+		addr = COLOUR_ALIGN(addr);
 
 	for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
 		/* At this point:  (!vma || addr < vma->vm_end). */
@@ -77,7 +79,8 @@
 		if (!vma || addr + len <= vma->vm_start)
 			return addr;
 		addr = vma->vm_end;
-		addr = COLOUR_ALIGN(addr);
+		if (filp)
+			addr = COLOUR_ALIGN(addr);
 	}
 }
 #endif


--
dwmw2

Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

dr...@re... said:
>  Then fix the kernel.  The change is necessary and correct. 

I believe the change was made for cache aliasing reasons - on SH4 we have a 
virtually-indexed cache with 8KiB-worth of entries, and we avoid having 
alias problems by allowing only even pages to be mapped at even addresses, 
and odd pages at odd addresses.

I haven't checked whether the kernel will make the offending mmap fail if 
you specify MAP_FIXED, or whether it'll fall back into cache-flushing mode, 
map the range uncached or deal with it some other way to give you the 
address you asked for. But surely unless you specify MAP_FIXED, the kernel 
is perfectly entitled to fix up the address to ensure cache sanity?

Why was it necessary to remove MAP_FIXED?

--
dwmw2

Re: [linuxsh-dev] Binutils 2.11.2 & SH

[Michael E. <ea...@mv...>]

"M. R. Brown" wrote:
> 
> * M. R. Brown <mr...@0x...> on Tue, Sep 11, 2001:
> 
> >
> > Also, what makes hardhat linux so different from sh-linux that it needs
> > it's own configure triplet?  Unless sh*-hardhat-linux modifies binutils in a
> > way that makes it incompatible with sh*-linux, you're just adding crud.
> > The configure scripts have long since supported *local*, it'd probably be
> > better to use that instead (e.g. sh4el-hardhat-linux-local).
> >
> 
> Whoops, I should've suggested that you not modify binutils to support this
> triplet at all.  It already supports sh[34]-*-linux, so you'd only be
> adding the config.sub stuff for sh[34]*[le] and sh[34]*[be], I suppose.
> 
> Sorry if I confused anyone :).

Our internal patches support sh[34]el and sh[34]eb.   We'd be happy 
to switch to something less ambiguous, sh[34]le, sh[34]be.

--
Michael Eager     ea...@mv...	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085

Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

[Ulrich D. <dr...@re...>]

"Bao C. Ha" <ba...@se...> writes:

> I am sending this message also to Ulrich Drepper, since
> the ChangeLog indicated that he removed the MAP_FIXED in
> the following.  It is causing problems running pthread
> applications in the sh4-linux environment.

Then fix the kernel.  The change is necessary and correct.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

RE: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

I am sending this message also to Ulrich Drepper, since
the ChangeLog indicated that he removed the MAP_FIXED in
the following.  It is causing problems running pthread
applications in the sh4-linux environment.

Following is the relevant segment of linuxthreads that is
broken:

In function pthread_allocate_stack(), file manager.c:
.......
#  ifdef _STACK_GROWS_DOWN
      new_thread = default_new_thread;
      new_thread_bottom = (char *) (new_thread + 1) - stacksize;
      map_addr = new_thread_bottom - guardsize;
      res_addr = mmap(map_addr, stacksize + guardsize,
                      PROT_READ | PROT_WRITE | PROT_EXEC,
                      MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
      if (res_addr != map_addr)
        {
          /* Bad luck, this segment is already mapped. */
          if (res_addr != MAP_FAILED)
            munmap (res_addr, stacksize + guardsize);
          return -1;
        }
.......

We resort to patching the MAP_FIXED back to linuxthreads
until we get a resolution on this problem.

Thanks.
Bao

> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of Bao C. Ha
> Sent: Tuesday, September 11, 2001 9:55 AM
> To: 'David Woodhouse'
> Cc: lin...@li...; lin...@m1...
> Subject: RE: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and
> 2.4.8 
> 
> 
> 
> > 
> > >  Is this supposed to be the correct area?  What changes 
> > make the newer
> > > kernels to return different pointers? 
> > 
> > Looking at the numbers, I'd be inclined to guess that it's 
> > moved due to
> > cache aliasing. And hence that it's not very likely to get 'fixed'. 
> > 
> Either the sh4 kernel has to be fixed, or linuxthread has to be fixed.
> MAP_FIXED was removed from linuxthreads sometimes earlier this year.
> Any serious applications using linuxthreads will exhibit the same
> problem.
> 
> Bao
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> 

RE: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

> 
> >  Is this supposed to be the correct area?  What changes 
> make the newer
> > kernels to return different pointers? 
> 
> Looking at the numbers, I'd be inclined to guess that it's 
> moved due to
> cache aliasing. And hence that it's not very likely to get 'fixed'. 
> 
Either the sh4 kernel has to be fixed, or linuxthread has to be fixed.
MAP_FIXED was removed from linuxthreads sometimes earlier this year.
Any serious applications using linuxthreads will exhibit the same
problem.

Bao

Re: [linuxsh-dev] Binutils 2.11.2 & SH

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

* M. R. Brown <mr...@0x...> on Tue, Sep 11, 2001:

> 
> Also, what makes hardhat linux so different from sh-linux that it needs
> it's own configure triplet?  Unless sh*-hardhat-linux modifies binutils in a
> way that makes it incompatible with sh*-linux, you're just adding crud.
> The configure scripts have long since supported *local*, it'd probably be
> better to use that instead (e.g. sh4el-hardhat-linux-local).
> 

Whoops, I should've suggested that you not modify binutils to support this
triplet at all.  It already supports sh[34]-*-linux, so you'd only be
adding the config.sub stuff for sh[34]*[le] and sh[34]*[be], I suppose.

Sorry if I confused anyone :).

M. R.

Re: [linuxsh-dev] Binutils 2.11.2 & SH

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

* Michael Eager <ea...@mv...> on Mon, Sep 10, 2001:

> 
> We have made some additional patches to binutils to support configuration
> as {sh3el,sh3eb,sh4el,sh4el}-hardhat-linux.  We will submit these to FSF.  
> I can also submit the patches for the previous release, if they have not
> been submitted yet.
> 

I've tried to point this out before, but the sh3el and sh3eb targets are
ambiguous since gcc supports a "m3e" or SH3E target.  Why not use sh*le and
sh*be instead?  Using the above method will only cause confusion when
someone decides to actually use the SH3E target (for sh-linux or sh-elf).

Also, what makes hardhat linux so different from sh-linux that it needs
it's own configure triplet?  Unless sh*-hardhat-linux modifies binutils in a
way that makes it incompatible with sh*-linux, you're just adding crud.
The configure scripts have long since supported *local*, it'd probably be
better to use that instead (e.g. sh4el-hardhat-linux-local).

M. R.

Re: [linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

ba...@se... said:
> One of our applications broke due to different behaviors of the system
> call old_mmap. 

You didn't specify MAP_FIXED. If the application relied on getting back the 
address it asked for then it's broken, as you discovered.

>  Is this supposed to be the correct area?  What changes make the newer
> kernels to return different pointers? 

Looking at the numbers, I'd be inclined to guess that it's moved due to
cache aliasing. And hence that it's not very likely to get 'fixed'. 

--
dwmw2

Re: [linuxsh-dev] Binutils 2.11.2 & SH

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

NIIBE Yutaka <gn...@m1...> wrote:
>> Let us know how we can encourage this to happen.
> 
> Kick Kaz. :-)  Seriously, please look and evaluate his patches.

I'm kicked. :-)

I've just sent a patch to binutils mailing list again. This patch
is to solve the relocation problem and was once not approved for
the ABI issue but is now reorganized as linux specific one.

	kaz

Re: [linuxsh-dev] Binutils 2.11.2 & SH

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

Michael Eager wrote:
 > We would like to see the SH support folded into the Binutils tree.

Yes, I agree.  We all love to see SH Linux support properly included
into Binutils, GCC and kernel mainline.

 > Let us know how we can encourage this to happen.

Kick Kaz. :-)  Seriously, please look and evaluate his patches.

In Japan, we have Linux Conference 2001 at end of this month, Debian
conference in October.  I think that those will be good opportunity to
submit/sync all the effort to mainline.

I've got a little budget for the development of this area (from
Japanese Government), and currently support Kaz and Sugioka-san this
year.  Hence, funding is OK for this financial year.
-- 

Re: [linuxsh-dev] Binutils 2.11.2 & SH

[Michael E. <ea...@mv...>]

Thanks for the quick reply.

We would like to see the SH support folded into the Binutils tree.
Let us know how we can encourage this to happen.

NIIBE Yutaka wrote:
> 
> Michael Eager wrote:
>  > I noticed that the SH patches to binutils-2.10.91.0.2 are not included
>  > in binutils-2.11.2.  Have they been submitted to the GNU maintainers?
> 
> Sort of.  It includes Linux specific ABI changes for relocation,
> configuration support for sh3,sh3eb,sh4,sh4eb, and -big option
> support.
> 
> IIRC, Linux specific ABI changes was discussed on binutils list, but
> it seemed there's no developpers related to sh-linux there, and it has
> not been included yet.  Last week, I've met Kaz and he said he will
> submit the changes again to the binutils list, RSN.
> 
> Configuration changes were proposed by Takeshi and Debian SH
> developpers last year.  The CPU name(s) are
> 
>         sh3, sh3eb, sh4, and sh4eb
> 
> as implemented in Linux kernel.  With Takeshi and Devian SH
> developpers, I've submitted changes to config-patches and libtool.
> Please check most resent version of config.guess, config.sub and
> libtool has support for those for CPU name.  The support for those
> four CPU configuration has not been submitted to the binutils list, as
> the first implementation was not so good and obviously affects other
> cases (sh-elf and etc.).  I think current patch has no issue for
> sh-elf.  I or Kaz will submit this change to binutils list.  Besides,
> the support for those four CPU configuration is submitted to GCC list,
> but it has not got a interest yet.
> --

--
Michael Eager     ea...@mv...	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085

[linuxsh-dev] Binutils 2.11.2 & SH

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

Michael Eager wrote:
 > I noticed that the SH patches to binutils-2.10.91.0.2 are not included 
 > in binutils-2.11.2.  Have they been submitted to the GNU maintainers?

Sort of.  It includes Linux specific ABI changes for relocation,
configuration support for sh3,sh3eb,sh4,sh4eb, and -big option
support.

IIRC, Linux specific ABI changes was discussed on binutils list, but
it seemed there's no developpers related to sh-linux there, and it has
not been included yet.  Last week, I've met Kaz and he said he will
submit the changes again to the binutils list, RSN.

Configuration changes were proposed by Takeshi and Debian SH
developpers last year.  The CPU name(s) are

	sh3, sh3eb, sh4, and sh4eb

as implemented in Linux kernel.  With Takeshi and Devian SH
developpers, I've submitted changes to config-patches and libtool.
Please check most resent version of config.guess, config.sub and
libtool has support for those for CPU name.  The support for those
four CPU configuration has not been submitted to the binutils list, as
the first implementation was not so good and obviously affects other
cases (sh-elf and etc.).  I think current patch has no issue for
sh-elf.  I or Kaz will submit this change to binutils list.  Besides,
the support for those four CPU configuration is submitted to GCC list,
but it has not got a interest yet.
-- 

[linuxsh-dev] Different old_mmap behavior in 2.4.5 and 2.4.8

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

We are moving from kernel 2.4.5 to kernel 2.4.8 and above.
One of our applications broke due to different behaviors
of the system call old_mmap.

In kernel 2.4.5:
307   old_mmap(0x7b7f7000, 36864, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7b7f7000

In kernel 2.4.8:
[pid   313] old_mmap(0x7b7f7000, 36864, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7b7f8000

In 2.4.5, we request 0x7b7f7000 and get the same area back.
In 2.4.8, we also request 0x7b7f7000, but we are getting a
different area pointed by 0x7b7f8000.

Is this supposed to be the correct area?  What changes make
the newer kernels to return different pointers?

Appreciate any pointers/suggestions.

Thanks.
Bao

[linuxsh-dev] Binutils 2.11.2 & SH

[Michael E. <ea...@mv...>]

I noticed that the SH patches to binutils-2.10.91.0.2 are not included 
in binutils-2.11.2.  Have they been submitted to the GNU maintainers?

We have made some additional patches to binutils to support configuration
as {sh3el,sh3eb,sh4el,sh4el}-hardhat-linux.  We will submit these to FSF.  
I can also submit the patches for the previous release, if they have not
been submitted yet.

(Please reply directly, I don't subscribe to the mailing lists.)
                                          
--
Michael Eager     ea...@mv...	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085

Re: [linuxsh-dev] Slight cleanup of CCR definitions.

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

gn...@m1... said:
>  Looks good.  If possible, please sync -sh4.c too.

/me digs out some SH4 docs.... OK. Untested but "Obviously Correct(tm)".

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.339
diff -u -r1.339 ChangeLog
--- ChangeLog	2001/09/10 08:59:59	1.339
+++ ChangeLog	2001/09/10 11:03:57
@@ -2,6 +2,7 @@
 
 	* arch/sh/mm/cache-sh3.c: Clearer definitions of CCR_CACHE_VAL and
 	CCR_CACHE_INIT.
+	* arch/sh/mm/cache-sh4.c: Likewise.
 
 2001-09-03  NIIBE Yutaka  <gn...@m1...>
 
Index: arch/sh/mm/cache-sh4.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.15
diff -u -r1.15 cache-sh4.c
--- arch/sh/mm/cache-sh4.c	2001/08/10 14:13:13	1.15
+++ arch/sh/mm/cache-sh4.c	2001/09/10 11:03:57
@@ -22,9 +22,21 @@
 #include <asm/mmu_context.h>
 
 #define CCR		 0xff00001c	/* Address of Cache Control Register */
-#define CCR_CACHE_VAL	 0x00000105	/* 8k+16k-byte cache,P1-wb,enable */
-#define CCR_CACHE_INIT	 0x0000090d	/* ICI,ICE(8k), OCI,P1-wb,OCE(16k) */
-#define CCR_CACHE_ENABLE 0x00000101
+
+#define CCR_CACHE_OCE	0x0001	/* Operand Cache Enable */
+#define CCR_CACHE_WT	0x0002	/* Write-Through (for P0,U0,P3) (else writeback)*/
+#define CCR_CACHE_CB	0x0004	/* Copy-Back (for P1) (else writethrough) */
+#define CCR_CACHE_OCI	0x0008	/* OC Invalidate */
+#define CCR_CACHE_ORA	0x0020	/* OC RAM Mode */
+#define CCR_CACHE_OIX	0x0080	/* OC Index Enable */
+#define CCR_CACHE_ICE	0x0100	/* Instruction Cache Enable */
+#define CCR_CACHE_ICI	0x0800	/* IC Invalidate */
+#define CCR_CACHE_IIX	0x8000	/* IC Index Enable */
+
+/* Default CCR setup: 8k+16k-byte cache,P1-wb,enable */
+#define CCR_CACHE_VAL	(CCR_CACHE_ICE|CCR_CACHE_CB|CCR_CACHE_OCE)
+#define CCR_CACHE_INIT	(CCR_CACHE_VAL|CCR_CACHE_OCI|CCR_CACHE_ICI)
+#define CCR_CACHE_ENABLE (CCR_CACHE_OCE|CCR_CACHE_ICE)
 
 #define CACHE_IC_ADDRESS_ARRAY 0xf0000000
 #define CACHE_OC_ADDRESS_ARRAY 0xf4000000

--
dwmw2

[linuxsh-dev] Slight cleanup of CCR definitions.

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

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

Looks good.  If possible, please sync -sh4.c too.
--