linuxsh-dev

[linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

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

Folks

I've uploaded a small patch to patch manager on SourceForge (and a copy
is also included in this email) for a few changes I've made here to the
serial port support:
 - configure the baud rate, bits, and parity for the serial console
   at boot time
 - record the clock values discovered at boot time in the cpuinfo info
   structure, and print the values as part of /proc/cpuinfo
 - use the peripherial module clock when calculating values for the SCI(F)
   baud rate (BBR)
 - pass through the baud rate from the serial console to the full serial
   driver
 - minimal support for the STMicroelectronics Overdrive board

I've set the default baud rate to 9600, which appears to be the default
for all other serial drivers. However the 'console' command line parameter
now works, so add something like:
  console=ttyS0,115200
to get the old behaviour back.

The patch is against the latest version on Sourceforge (as of 09:00
24th May).

Unfortunatly some of this clashes with the patch generated by 
Pierre-Philippe. I think we had similar objectives for the SCI changes,
although his patch also contains quite a few other things which are specific
to his hardware. IMHO this way of doing things is a bit more general.
By the way, Pierre's patch on sourceforge appears to be corrupt.

Stuart


---------------------------------------------------------------------------
Index: kernel/arch/sh/config.in
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/config.in,v
retrieving revision 1.5
diff -u -r1.5 config.in
--- kernel/arch/sh/config.in	2000/05/04 06:32:44	1.5
+++ kernel/arch/sh/config.in	2000/05/24 10:44:03
@@ -17,28 +17,47 @@
 comment 'Processor type and features'
 choice 'SuperH system type'					\
 	"Generic		CONFIG_SH_GENERIC		\
-	 SolutionEngine		CONFIG_SH_SOLUTION_ENGINE" Generic
+	 SolutionEngine		CONFIG_SH_SOLUTION_ENGINE \
+	 Overdrive		CONFIG_SH_OVERDRIVE" Generic
 
-choice 'Processor type' \
-   "SH7708 CONFIG_CPU_SUBTYPE_SH7708 \
-    SH7709 CONFIG_CPU_SUBTYPE_SH7709 \
-    SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708
-if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then
-   define_bool CONFIG_CPU_SH3 y
-   define_bool CONFIG_CPU_SH4 n
-fi
-if [ "$CONFIG_CPU_SUBTYPE_SH7709" = "y" ]; then
-   define_bool CONFIG_CPU_SH3 y
-   define_bool CONFIG_CPU_SH4 n
-fi
-if [ "$CONFIG_CPU_SUBTYPE_SH7750" = "y" ]; then
-   define_bool CONFIG_CPU_SH3 n
-   define_bool CONFIG_CPU_SH4 y
+
+if [ "$CONFIG_SH_OVERDRIVE" = "n" ]; then
+  choice 'Processor type' \
+     "SH7708 CONFIG_CPU_SUBTYPE_SH7708 \
+      SH7709 CONFIG_CPU_SUBTYPE_SH7709 \
+      SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708
+  if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then
+     define_bool CONFIG_CPU_SH3 y
+     define_bool CONFIG_CPU_SH4 n
+  fi
+  if [ "$CONFIG_CPU_SUBTYPE_SH7709" = "y" ]; then
+     define_bool CONFIG_CPU_SH3 y
+     define_bool CONFIG_CPU_SH4 n
+  fi
+  if [ "$CONFIG_CPU_SUBTYPE_SH7750" = "y" ]; then
+     define_bool CONFIG_CPU_SH3 n
+     define_bool CONFIG_CPU_SH4 y
+  fi
+else
+  define_bool CONFIG_CPU_SUBTYPE_SH7708 n
+  define_bool CONFIG_CPU_SUBTYPE_SH7709 n
+  define_bool CONFIG_CPU_SUBTYPE_SH7750 y
+  define_bool CONFIG_CPU_SH3 n
+  define_bool CONFIG_CPU_SH4 y
 fi
+
 bool 'Little Endian' CONFIG_LITTLE_ENDIAN
+
 if [ "$CONFIG_SH_SOLUTION_ENGINE" = "y" ]; then
   define_hex CONFIG_MEMORY_START 0c000000
-else
+fi
+
+if [ "$CONFIG_SH_OVERDRIVE" = "y" ]; then
+  define_hex CONFIG_MEMORY_START 0c000000
+  define_hex CONFIG_IOPORT_START ba000000
+fi
+
+if [ "$CONFIG_SH_GENERIC" = "y" ]; then
   hex 'Physical memory start address' CONFIG_MEMORY_START 08000000
   hex 'I/O port offset address' CONFIG_IOPORT_START ba000000
 fi
Index: kernel/arch/sh/kernel/Makefile
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- kernel/arch/sh/kernel/Makefile	2000/05/03 02:24:42	1.3
+++ kernel/arch/sh/kernel/Makefile	2000/05/24 10:44:03
@@ -28,6 +28,10 @@
 O_OBJS += setup_se.o io_se.o
 endif
 
+ifdef CONFIG_SH_OVERDRIVE
+O_OBJS += setup_od.o io_generic.o
+endif
+
 ifdef CONFIG_CPU_SH4
 O_OBJS += fpu.o
 endif
Index: kernel/arch/sh/kernel/setup.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/setup.c,v
retrieving revision 1.3
diff -u -r1.3 setup.c
--- kernel/arch/sh/kernel/setup.c	2000/04/28 17:58:50	1.3
+++ kernel/arch/sh/kernel/setup.c	2000/05/24 10:44:03
@@ -327,5 +327,13 @@
 		     (loops_per_sec+2500)/500000,
 		     ((loops_per_sec+2500)/5000) % 100);
 
+#define PRINT_CLOCK(name, value) \
+	p += sprintf(p, name " clock: %d.%02dMHz\n", \
+		     ((value) / 1000000), ((value) % 1000000)/10000)
+	
+	PRINT_CLOCK("CPU", boot_cpu_data.cpu_clock);
+	PRINT_CLOCK("Bus", boot_cpu_data.bus_clock);
+	PRINT_CLOCK("Peripherial module", boot_cpu_data.module_clock);
+
 	return p - buffer;
 }
Index: kernel/arch/sh/kernel/time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.9
diff -u -r1.9 time.c
--- kernel/arch/sh/kernel/time.c	2000/05/14 08:41:25	1.9
+++ kernel/arch/sh/kernel/time.c	2000/05/24 10:44:04
@@ -444,6 +444,11 @@
 
 	printk("Interval = %ld\n", interval);
 
+	current_cpu_data.cpu_clock    = cpu_clock;
+	current_cpu_data.master_clock = master_clock;
+	current_cpu_data.bus_clock    = bus_clock;
+	current_cpu_data.module_clock = module_clock;
+
 	/* Start TMU0 */
 	ctrl_outb(TMU_TOCR_INIT, TMU_TOCR);
 	ctrl_outw(TMU0_TCR_INIT, TMU0_TCR);
Index: kernel/drivers/char/sh-sci.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v
retrieving revision 1.8
diff -u -r1.8 sh-sci.c
--- kernel/drivers/char/sh-sci.c	2000/05/22 09:41:31	1.8
+++ kernel/drivers/char/sh-sci.c	2000/05/24 10:44:05
@@ -31,7 +31,9 @@
 #include <linux/malloc.h>
 #include <linux/init.h>
 #include <linux/delay.h>
+#ifdef CONFIG_SERIAL_CONSOLE
 #include <linux/console.h>
+#endif
 
 #include <asm/system.h>
 #include <asm/io.h>
@@ -50,6 +52,10 @@
 
 struct sci_port sci_ports[1];
 
+#ifdef CONFIG_SERIAL_CONSOLE
+static struct console sercons;
+#endif
+
 /* Function prototypes */
 static void sci_disable_tx_interrupts(void *ptr);
 static void sci_enable_tx_interrupts(void *ptr);
@@ -114,11 +120,11 @@
 */
 }
 
-static void sci_set_baud(struct sci_port *port)
+static void sci_set_baud(int baud)
 {
 	int t;
 
-	switch (port->gs.baud) {
+	switch (baud) {
 	case 0:
 		t = -1;
 		break;
@@ -138,14 +144,14 @@
 		t = BPS_38400;
 		break;
 	default:
-		printk(KERN_INFO "sci: unsupported baud rate: %d, use 115200 instead.\n", port->gs.baud);
+		printk(KERN_INFO "sci: unsupported baud rate: %d, use 115200 instead.\n", baud);
 	case 115200:
 		t = BPS_115200;
 		break;
 	}
 
 	if (t > 0) {
-		sci_setsignals (port, 1, -1);
+		/* sci_setsignals (port, 1, -1); */
 		if(t >= 256) {
 			ctrl_out((ctrl_in(SCSMR) & ~3) | 1, SCSMR);
 			t >>= 2;
@@ -155,11 +161,11 @@
 		while (ctrl_inw(RFCR) < WAIT_RFCR_COUNTER)
 			;
 	} else {
-		sci_setsignals (port, 0, -1);
+		/* sci_setsignals (port, 0, -1); */
 	}
 }
 
-static void sci_set_termios_cflag(struct sci_port *port)
+static void sci_set_termios_cflag(int cflag, int baud)
 {
 	unsigned short status;
 	unsigned short smr_val;
@@ -171,8 +177,6 @@
 		status = ctrl_in(SC_SR);
 	while (!(status & SCI_TEND));
 
-	port->old_cflag = port->gs.tty->termios->c_cflag;
-
 	ctrl_out(0x00, SCSCR);	/* TE=0, RE=0, CKE1=0 */
 #if defined(CONFIG_SH_SCIF_SERIAL)
 	ctrl_out(fcr_val, SCFCR);
@@ -180,13 +184,13 @@
 #endif
 
 	smr_val = ctrl_in(SCSMR) & 3;
-	if ((port->gs.tty->termios->c_cflag & CSIZE) == CS7)
+	if ((cflag & CSIZE) == CS7)
 		smr_val |= 0x40;
-	if (C_PARENB(port->gs.tty))
+	if (cflag & PARENB)
 		smr_val |= 0x20;
-	if (C_PARODD(port->gs.tty))
+	if (cflag & PARODD)
 		smr_val |= 0x10;
-	if (C_CSTOPB(port->gs.tty))
+	if (cflag & CSTOPB)
 		smr_val |= 0x08;
 	ctrl_out(smr_val, SCSMR);
 
@@ -201,7 +205,7 @@
 		ctrl_outw(data&0x0fcf, SCPCR); 
 	}
 #endif
-	if (C_CRTSCTS(port->gs.tty))
+	if (cflag & CRTSCTS)
 		fcr_val |= 0x08;
 	else {
 #if defined(__sh3__)
@@ -223,17 +227,19 @@
 	ctrl_out(fcr_val, SCFCR);
 #endif
 
-	sci_set_baud(port);
+	sci_set_baud(baud);
 	ctrl_out(SCSCR_INIT, SCSCR);	/* TIE=0,RIE=0,TE=1,RE=1 */
-	sci_enable_rx_interrupts(port);
 }
 
 static int sci_set_real_termios(void *ptr)
 {
 	struct sci_port *port = ptr;
 
-	if (port->old_cflag != port->gs.tty->termios->c_cflag)
-		sci_set_termios_cflag(port);
+	if (port->old_cflag != port->gs.tty->termios->c_cflag) {
+		port->old_cflag = port->gs.tty->termios->c_cflag;
+		sci_set_termios_cflag(port->old_cflag, port->gs.baud);
+		sci_enable_rx_interrupts(port);
+	}
 
 	/* Tell line discipline whether we will do input cooking */
 	if (I_OTHER(port->gs.tty))
@@ -521,6 +527,13 @@
 	port->gs.tty = tty;
 	port->gs.count++;
 
+#ifdef CONFIG_SERIAL_CONSOLE
+	if (sercons.cflag && sercons.index == line) {
+		tty->termios->c_cflag = sercons.cflag;
+		sercons.cflag = 0;
+	}
+#endif
+
 	/*
 	 * Start up serial port
 	 */
@@ -687,7 +700,7 @@
 	sci_driver.subtype = SERIAL_TYPE_NORMAL;
 	sci_driver.init_termios = tty_std_termios;
 	sci_driver.init_termios.c_cflag =
-		B115200 | CS8 | CREAD | HUPCL | CLOCAL | CRTSCTS;
+		B9600 | CS8 | CREAD | HUPCL | CLOCAL | CRTSCTS;
 	sci_driver.flags = TTY_DRIVER_REAL_RAW;
 	sci_driver.refcount = &sci_refcount;
 	sci_driver.table = sci_table;
@@ -851,7 +864,7 @@
  */
 static int __init serial_console_setup(struct console *co, char *options)
 {
-	int	baud = 115200;
+	int	baud = 9600;
 	int	bits = 8;
 	int	parity = 'n';
 	int	cflag = CREAD | HUPCL | CLOCAL;
@@ -885,6 +898,7 @@
 		case 9600:
 		default:
 			cflag |= B9600;
+			baud = 9600;
 			break;
 	}
 	switch (bits) {
@@ -905,8 +919,9 @@
 			break;
 	}
 	co->cflag = cflag;
+
+	sci_set_termios_cflag(cflag, baud);
 
-	/* XXX: set baud, char, and parity here. */
 	return 0;
 }
 
Index: kernel/drivers/char/sh-sci.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.h,v
retrieving revision 1.6
diff -u -r1.6 sh-sci.h
--- kernel/drivers/char/sh-sci.h	2000/05/22 09:41:31	1.6
+++ kernel/drivers/char/sh-sci.h	2000/05/24 10:44:05
@@ -193,22 +193,17 @@
  * the SCSMR register would also need to be set to non-zero values.
  *
  * -- Greg Banks 27Feb2000
+ *
+ * Answer: The SCBRR register is only eight bits, and the value in
+ * it gets larger with lower baud rates. At around 2400 (depending on
+ * the peripherial module clock) you run out of bits. However the
+ * lower two bits of SCSMR allow the module clock to be divided down,
+ * scaling the value which is needed in SCBRR.
+ *
+ * -- Stuart Menefy - 23 May 2000
  */
 
-/*
- * XXX: Well, this is not relevant...
- * Should we have config option for peripheral clock?
- * Or we get the value from time.c.
- */
-#if defined(__sh3__)
-#if defined(CONFIG_CPU_SUBTYPE_SH7709)
-#define PCLK           33333333
-#else
-#define PCLK           14745600	/* Isn't it 15MHz? */
-#endif
-#elif defined(__SH4__)
-#define PCLK           33333333
-#endif
+#define PCLK           (current_cpu_data.module_clock)
 
 #define SCBRR_VALUE(bps) (PCLK/(32*bps)-1)
 #define BPS_2400       SCBRR_VALUE(2400)
Index: kernel/include/asm-sh/processor.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/processor.h,v
retrieving revision 1.2
diff -u -r1.2 processor.h
--- kernel/include/asm-sh/processor.h	2000/04/14 17:25:44	1.2
+++ kernel/include/asm-sh/processor.h	2000/05/24 10:44:09
@@ -36,6 +36,7 @@
 	unsigned long *pgd_quick;
 	unsigned long *pte_quick;
 	unsigned long pgtable_cache_sz;
+	unsigned int cpu_clock, master_clock, bus_clock, module_clock;
 };
 
 extern struct sh_cpuinfo boot_cpu_data;
Index: kernel/arch/sh/kernel/setup_od.c
===================================================================
diff -u -r0.0 setup_od.c
--- /dev/null   Tue May  5 21:32:27 1998
+++ kernel/arch/sh/kernel/setup_od.c   Tue May 23 22:15:48 2000
@@ -0,0 +1,35 @@
+/* $Id$
+ *
+ * linux/arch/sh/kernel/setup_od.c
+ *
+ * Copyright (C) 2000  Stuart Menefy
+ *
+ * STMicroelectronics Overdrive Support.
+ *
+ */
+
+#include <linux/config.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+
+/*
+ * Initialize the board
+ */
+int __init setup_od(void)
+{
+	/* Enable RS232 receive buffers */
+	volatile int* p = (volatile int*)0xa3000000;
+
+#if defined(CONFIG_SH_ORION)
+	*p=1;
+#elif defined(CONFIG_SH_OVERDRIVE)
+	*p=0x1e;
+#else
+#error Illegal configuration
+#endif
+
+	printk(KERN_INFO "STMicroelectronics Overdrive Setup...done\n");
+	return 0;
+}
+
+module_init(setup_od);

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

[Mitch D. <mj...@au...>]

Hi Stuart!

Stuart Menefy wrote:
> 
> I've uploaded a small patch to patch manager on SourceForge (and a
> copy is also included in this email)

Cool, thanks.  BTW I like the feature list of this patch.

> Unfortunatly some of this clashes with the patch generated by
> Pierre-Philippe. I think we had similar objectives for the SCI
> changes, although his patch also contains quite a few other things
> which are specific to his hardware. IMHO this way of doing things
> is a bit more general.

General is good.  There are two ways to work this out.
The first is to choose one patch, check it in first, then the
other person has the job of resolving conflicts and making
sure their code works too.  They will then resubmit this patch.
You'll need to work out who goes first with Pierre.

The second is to get in touch with Pierre and privately
work out how you both want the code to look and work.
When you both have something unified that you like, that's
what gets submitted.

Another idea is to submit smaller non-clashing patches
which do less.  This will tend to just leave the areas which
really do clash and you and he can concentrate on these areas.
An example might be splitting this patch into two - a patch
for the serial stuff, and a patch to add support for the
STM OverDrive board.

Note, normally this problem would not have arisen, because
patches like Pierre's would have been applied much earlier,
instead of being left unhandled.

At the time Pierre sent this patch, I felt it had changes for
his hardware which were not sufficiently wrapped to isolate
them from the generic code, so I didn't push for its inclusion.
But it _is_ my fault for not communicating that to him so he
could revise it.  Sorry Pierre!

Soon I will have some serious time to spend on this project,
and this sort of problem will be less likely to reoccur.

> By the way, Pierre's patch on sourceforge appears to be corrupt.

I put that patch there by saving the mail that was sent to the
mailing list.  It's possible Netscape mangled it at Save As
time.  I've noted both the fixing of the corruption, and
the resolving of his patch in my TO-DO list.  

Alternatively, Pierre, could you put a new version of your patch
on SourceForge please?  Here's the URL:

  http://sourceforge.net/patch/?func=detailpatch&patch_id=100369&group_id=2682

Stuart, at m17n we discussed public discussion of patches, so
hope you don't mind my comments.

> +if [ "$CONFIG_SH_OVERDRIVE" = "n" ]; then
> +  choice 'Processor type' \
> +     "SH7708 CONFIG_CPU_SUBTYPE_SH7708 \
> +      SH7709 CONFIG_CPU_SUBTYPE_SH7709 \
> +      SH7750 CONFIG_CPU_SUBTYPE_SH7750" SH7708
> +  if [ "$CONFIG_CPU_SUBTYPE_SH7708" = "y" ]; then
> +     define_bool CONFIG_CPU_SH3 y
> +     define_bool CONFIG_CPU_SH4 n
> +  fi

One thing which occurs to me is that the Alpha people have
this problem, but even more so.  That is, dozens and dozens
of different boards, each with different CPUs and slightly
different peripherals.  It might be worth having a look at
how they've done things to see if there are ideas worth 
stealing.

> +++ kernel/arch/sh/kernel/setup.c       2000/05/24 10:44:03
> +#define PRINT_CLOCK(name, value) \
> +       p += sprintf(p, name " clock: %d.%02dMHz\n", \
> +                    ((value) / 1000000), ((value) % 1000000)/10000)
> +
> +       PRINT_CLOCK("CPU", boot_cpu_data.cpu_clock);
> +       PRINT_CLOCK("Bus", boot_cpu_data.bus_clock);
> +       PRINT_CLOCK("Peripherial module", boot_cpu_data.module_clock);

s/Peripherial/Peripheral/

> --- kernel/drivers/char/sh-sci.c        2000/05/22 09:41:31     1.8
>         } else {
> -               sci_setsignals (port, 0, -1);
> +               /* sci_setsignals (port, 0, -1); */
>         }

Just out of curiosity, what did sci_setsignals do?

> -#if defined(__sh3__)
> -#if defined(CONFIG_CPU_SUBTYPE_SH7709)
> -#define PCLK           33333333
> -#else
> -#define PCLK           14745600        /* Isn't it 15MHz? */
> -#endif
> -#elif defined(__SH4__)
> -#define PCLK           33333333
> -#endif
> +#define PCLK           (current_cpu_data.module_clock)

This is waaaaay cool! :-)

> +++ kernel/arch/sh/kernel/setup_od.c   Tue May 23 22:15:48 2000
> @@ -0,0 +1,35 @@
> +/* $Id$
> + *
> + * linux/arch/sh/kernel/setup_od.c
> + *
> + * Copyright (C) 2000  Stuart Menefy
> + *
> + * STMicroelectronics Overdrive Support.

Just a general note to people doing work while in the employ
of companies: To protect yourself, your employer and the Linux
kernel, it might be a good idea to get something signed to say
that your company doesn't regard the code as its intellectual
property.  Saying it's licensed under the GPL can't hurt either.

> +int __init setup_od(void)
> +{
> +       /* Enable RS232 receive buffers */
> +       volatile int* p = (volatile int*)0xa3000000;
> +
> +#if defined(CONFIG_SH_ORION)

Is this defined elsewhere?  Would you like it to be?

-- 

In all, a nice patch.  Thank you.

Regards,

Mitch.
--
| mailto:mj...@au...       | Not the official view of: |
| mailto:mj...@al... | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

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

Folks

I'm glad my SCI patch caused some discussions!

Unfortunately as Pierre-Philippe as not working with SuperH any more,
I'm reluctant to checkin the board specific changes he made, as nobody
will be able to test them. However the 7707 changes looked worth
having.  If I try and incorporate then, is there anyone out there who
could test them?

So I'll go ahead and check in my changes when I'm next back in work
(which will be Tuesday now) unless I hear any different.

>> Alternatively, Pierre, could you put a new version of your patch
>> on SourceForge please?  Here's the URL:

Mitch, thanks for doing this. I couldn't see a way of getting a
plain text version out of the mailing list archive.

>> Stuart, at m17n we discussed public discussion of patches, so
>> hope you don't mind my comments.

Not at all, its good to get some feedback.

>> One thing which occurs to me is that the Alpha people have
>> this problem, but even more so.  That is, dozens and dozens
>> of different boards, each with different CPUs and slightly
>> different peripherals.  It might be worth having a look at
>> how they've done things to see if there are ideas worth 
>> stealing.

I agree. My feeling is that the SuperH port of Linux will probably be the
first which is targeted at embedded systems from the outset, so it
would be good to try and get the support for large number of variants
right at the start. We also want to try and make it as simple as possible
for users to add support for custom hardware.

I'll try and have a look at some of the other ports in the next few
days and make some proposals for how we could proceed. My colleague is
adding PCI support for the Overdrive here at the moment, so the number
of board specific files has mushroomed. So this is an issue we have a
direct interest in solving!

>> Just out of curiosity, what did sci_setsignals do?

In the current version, nothing. The comment says that it is there to
handle modem control lines, but nothing has been implemented, so
commenting it out has no effect. I guess we will need something for
the future, but that is going to be another bit of board specific
code.

Actually you've found me out, this was a bit of a hack to get things
going!  My only defence is that I've started making more changes to
these files to add support for multiple SCI and SCIF ports, so I'll
keep it there for the moment until someone needs to do something real
with it.

>> Just a general note to people doing work while in the employ
>> of companies: To protect yourself, your employer and the Linux
>> kernel, it might be a good idea to get something signed to say
>> that your company doesn't regard the code as its intellectual
>> property.  Saying it's licensed under the GPL can't hurt either.

Good point. I've started making enquiries about this at ST.  Mitch, I
thing you mentioned that you'd had to do something similar. Did you
find the few lines at the end of the GPL sufficient:

  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
  `Gnomovision' (which makes passes at compilers) written by James Hacker.

  <signature of Ty Coon>, 1 April 1989
  Ty Coon, President of Vice

I have a nasty feeling I'm going to need something more to keep the
lawyers happy, and management won't sign until they are.

Stuart

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

[Mitch D. <mj...@au...>]

Stuart Menefy wrote:
> 
> I'm glad my SCI patch caused some discussions!

:-)

> Unfortunately as Pierre-Philippe as not working with SuperH any more,
> I'm reluctant to checkin the board specific changes he made

Yes.  I felt guilty that the patch had not been acted on, since I
think Pierre deserves to see his work bear fruit.  However since
he's acknowledged it wasn't polished, and he's now not working on
it, I don't feel compelled to check in his patch as it stands.

However, I'll shortly be doing some work on the 7707 myself,
and I will be taking his patch and pulling all the good things
out of it, so his work will certainly not be wasted.  Thanks
Pierre!

> So I'll go ahead and check in my changes when I'm next back in work
> (which will be Tuesday now) unless I hear any different.

Just as a matter of practice, if you upload a new version of your
patch to SourceForge, I'm very happy to check it in.  (Remember
that small typo?)

> I'll try and have a look at some of the other ports in the next few
> days and make some proposals for how we could proceed. My colleague is
> adding PCI support for the Overdrive here at the moment, so the number
> of board specific files has mushroomed. So this is an issue we have a
> direct interest in solving!

Cool.

> >> Just a general note to people doing work while in the employ
> >> of companies: To protect yourself, your employer and the Linux
> >> kernel, it might be a good idea to get something signed to say
> >> that your company doesn't regard the code as its intellectual
> >> property.  Saying it's licensed under the GPL can't hurt either.
> 
> Good point. I've started making enquiries about this at ST.  Mitch, I
> thing you mentioned that you'd had to do something similar.

Yes, I arranged for HP to GPL the software to connect PCs to HP
calculators.  (http://www.hpcomm.org).  I got an HP attorney to
agree, then my manager did.

> Did you find the few lines at the end of the GPL sufficient:

I think they are sufficient.  I didn't do it, but it sounds
like a good idea.

> I have a nasty feeling I'm going to need something more to keep the
> lawyers happy, and management won't sign until they are.

Mgmt told me the lawyers had to be happy before they were.  I
had to hunt for a long time before I found a lawyer inside of
HP who specialised in intellectual property, from a free
software perspective.

If I were in the position of advocating the use of Linux within
a product, I think emphasising the intellectual property issues
(esp in terms of "ownership", limitation of liability, support
responsibility, etc) is as important as the technical benefits.

Regards,

Mitch.
--
| mailto:mj...@au...       | Not the official view of: |
| mailto:mj...@al... | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

[linuxsh-dev] Re: Patch: Boot time configuration of SCI(F) and Overdrive support

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

Stuart Menefy wrote:
 > >> Just out of curiosity, what did sci_setsignals do?
 > 
 > In the current version, nothing. The comment says that it is there to
 > handle modem control lines, but nothing has been implemented, so
 > commenting it out has no effect. I guess we will need something for
 > the future, but that is going to be another bit of board specific
 > code.

What I thought was:
	(a) SCI doesn't have flow control feature with that
	(b) Someone may implement RTS/CTS using some port signal,
	    for his board
	(c) In that case, he may want to implement it here. 

 > Actually you've found me out, this was a bit of a hack to get things
 > going!  My only defence is that I've started making more changes to
 > these files to add support for multiple SCI and SCIF ports, so I'll
 > keep it there for the moment until someone needs to do something real
 > with it.

Please go ahead!  Currently, SCI and SCIF is compile time option.  At
that time, I didn't understand SH7750 (or SH7709) has both of SCI and
SCIF.  It would be good if:

	(1) We use both of SCI and SCIF.
	(2) We can change which is primary on runtime. (command line option)

Thought?
-- 

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

[<pi...@li...>]

Hello Mitch,

Mitch Davis wrote:

--8<--8<--SNIP-SNIP--8<--8<--

> You'll need to work out who goes first with Pierre.

You can mail me directly at : pi...@li...

--8<--8<--SNIP-SNIP--8<--8<--

> At the time Pierre sent this patch, I felt it had changes for
> his hardware which were not sufficiently wrapped to isolate
> them from the generic code, so I didn't push for its inclusion.
> But it _is_ my fault for not communicating that to him so he
> could revise it.  Sorry Pierre!

No problem :-) my changes are neither fancy nor general. They just served my
purpose at the time because my focus was on something else.

--8<--8<--SNIP-SNIP--8<--8<--

> Alternatively, Pierre, could you put a new version of your patch
> on SourceForge please?  Here's the URL:

Will do.

I think you guys should know that the SH3 project I was working on has been
canned : some corpy business guy pulled the plug on our pending contract at our
customer's company  because he "didn't understand where that Linux thing could
possibly lead the company". So, effectively, I have definitely ceased my work on
Hitachi processors.

Sorry everybody, I really didn't expect that : some people just don't understand
what an opportunity Linux is, and how good and finalized the work Niibe-San and
everybody did with LinuxSH has become.

Take care, and good luck

--
 ______ __      __  __   __  _____  ____
 _____ / /     / / /  | / / / ___/ / __ \
 ____ / /     / / /   |/ / / /_   / / / /
 ___ / /     / / / /|   / / __/  / / / /
 __ / /___  / / / / |  / / /___ / /_/ /
 _ /_____/ /_/ /_/  |_/ /_____/ \____/

                  ////\
                  (@ @)
--------------oOOo-(_)-oOOo---------------
Pierre-Philippe Coupard
Software Engineer, Lineo, Inc.
Email : pi...@li...
Phone : (801) 426-5001 x 208
------------------------------------------

It is not a good omen when goldfish commit suicide.

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

[Mitch D. <mj...@au...>]

Hi Pierre,

pi...@li... wrote:
> 
> No problem :-) my changes are neither fancy nor general.
> They just served my purpose at the time because my focus
> was on something else.

I thought that would be so.  Still, we are very glad to have it.
From this we can help our project.

> I think you guys should know that the SH3 project I was
> working on has been canned :

Pierre, I'm really very sorry to hear that.

Since it's inevitable that your kernel code would have to
be released under the GPL, can I encourage you to see if it's
possible for Lineo to release the code-so-far under the GPL?

> some corpy business guy

Suits.  It's always the suits.  :-|

> So, effectively, I have definitely ceased my work on
> Hitachi processors.

You've made a significant investment in learning this stuff,
why throw your knowledge away now?  Most of us do this for
fun and outside our companies.  There's nothing to stop you
from doing the same, and heaven knows, our project could
really benefit from having you.  Is there nothing we can do?  

> how good and finalized the work Niibe-San and
> everybody did with LinuxSH has become.

Yes quite.  You can still be a part of it.

Regards,

Mitch.
--
| mailto:mj...@au...       | Not the official view of: |
| mailto:mj...@al... | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

[<pi...@li...>]

Mitch Davis wrote:

--8<--8<--SNIP-SNIP--8<--8<--

> Since it's inevitable that your kernel code would have to
> be released under the GPL, can I encourage you to see if it's
> possible for Lineo to release the code-so-far under the GPL?

Most of my work has been concentrated on getting a solid bootloader for
the Hypercom board I was working on, as well as Linux equivalents for
some of the tools that are part of the WindowsCE builder 2.1.2, like
CESH.

I definitely can't disclose the bootloader as it contains bits of
Microsoft code and probably would divulge Hypercom's hardware design by
the very code I used to initialize the board. As for the tools, instead
of using M$' "BIN" format, I did my own ("LIN" format") that does pretty
much the same, and implement CRC verification and all, but is not
Microsoft's. So, a priori, it should be ok to GPL but I need to ask what
Lineo's intentions are with them.

As for the kernel, the only work I did is all contained in that patch
that I sent the other day, and we certainly want it to be GPL.

> > some corpy business guy
>
> Suits.  It's always the suits.  :-|

<PERSONAL OPINION> Well, I don't mind the suits, they are useful and
needed in a company, but I wish short-sighted ones were not given a
voice in corporate meetings </PERSONAL OPINION>.

> > So, effectively, I have definitely ceased my work on
> > Hitachi processors.
>
> You've made a significant investment in learning this stuff,
> why throw your knowledge away now?  Most of us do this for
> fun and outside our companies.  There's nothing to stop you
> from doing the same, and heaven knows, our project could
> really benefit from having you.  Is there nothing we can do?
>
> > how good and finalized the work Niibe-San and
> > everybody did with LinuxSH has become.
>
> Yes quite.  You can still be a part of it.

Thanks, I appreciate the comments. In fact, I'm not junking what I did
and learned away : I'm transitioning my work over to our Japanese office
who is already busy making good use of the work you guys are doing on
SH4 Aspen boards. It also looks like they'll be doing work on ST40
processors soon, although nothing is sure with that yet. As for me, I'm
moving to the MIPS processors.

Unfortunately, I probably won't be able to do SH work in my spare time.
The reasons are that I won't have the hardware in my disposition
anymore, and I have other ongoing projects as well that sure eat up my
time :-)

I'll be watching the mailing list though, I think the LinuxSH effort is
really getting somewhere and is gaining tremendous momentum.

Take care,

--
 ______ __      __  __   __  _____  ____
 _____ / /     / / /  | / / / ___/ / __ \
 ____ / /     / / /   |/ / / /_   / / / /
 ___ / /     / / / /|   / / __/  / / / /
 __ / /___  / / / / |  / / /___ / /_/ /
 _ /_____/ /_/ /_/  |_/ /_____/ \____/

                  ////\
                  (@ @)
--------------oOOo-(_)-oOOo---------------
Pierre-Philippe Coupard
Software Engineer, Lineo, Inc.
Email : pi...@li...
Phone : (801) 426-5001 x 208
------------------------------------------

Raising pet electric eels is gaining a lot of current popularity.

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

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

Ouch.  I miss you Pierre.  I'm sorry that I couldn't include your
changes yet.  I'm sure that your idea will goes into the kernel
eventually.  I don't know if we can support SH7707 or not, though.

If you have comments about idea below, please let us know.

Upon your suggestion of building all of the things into one image,
I've been thinking like that:

   (1) Keep the kernel as portable if possible
       (not include BSC setting and so)

   (2) Place the hardware specific initialization
       under arch/sh/boot/machine/

   (3) Offer some script generating image (say, S-record or bare binary)
       from vmlinux and the hardware specific initialization

   (4) If needed, develop some tool writing Flash-ROM
       (for specific hardware: CqREEK SH4 or APSH4)
-- 

Re: [linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

[Mitch D. <mj...@au...>]

Stuart Menefy wrote:
> 
> By the way, Pierre's patch on sourceforge appears to be corrupt.

Please be advised that Pierre sent me a more recent version,
which I have uploaded to SourceForge.  Stuart, would you mind
confirming whether or not it's corrupted please?

PS: It may not apply cleanly because it was diffed against an older
kernel.  You may like to try the "--dry-run" option to "patch" first.

Thanks,

Regards,

Mitch.
--
| mailto:mj...@au...       | Not the official view of: |
| mailto:mj...@al... | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

[linuxsh-dev] Patch: Boot time configuration of SCI(F) and Overdrive support

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

Stuart Menefy wrote:
 > I've uploaded a small patch to patch manager on SourceForge (and a copy
 > is also included in this email) for a few changes I've made here to the
 > serial port support:
 >  - configure the baud rate, bits, and parity for the serial console
 >    at boot time
 >  - record the clock values discovered at boot time in the cpuinfo info
 >    structure, and print the values as part of /proc/cpuinfo
 >  - use the peripherial module clock when calculating values for the SCI(F)
 >    baud rate (BBR)
 >  - pass through the baud rate from the serial console to the full serial
 >    driver
 >  - minimal support for the STMicroelectronics Overdrive board

Wow great!  Patch looks sane.  Stuart, could you please commit this?
--