linuxsh-dev

[linuxsh-dev] Today's addition

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

... is support of SH7709A.

To compare the behavior (of SH-4), I worked for SH7709A (in the
office).  It's another SolutionEngine.  It also failed with RAMDISK
support (like SH-4).

In my home, SH7708 works fine (with no RAMDISK), RAMDISK may be the
cause.

It would be good if PCLK is _not_ constant, but get the value from
time.c.

I'll commit this tomorrow.

--------------------------
2000-05-01  NIIBE Yutaka  <gn...@m1...>

	Support of SH7709A.
	* arch/sh/kernel/time.c (do_timer_interrupt): Remove Takeshi's
	debugging code (output to Port C).

	* drivers/char/sh-sci.h (PCLK): Added value for my SH7709A board.
	* drivers/char/sh-sci.c (sci_set_termios_cflag): Added SH7709's
	SCPCR/SCPDR handling.
	(put_char, get_char): Added dummy read of SC_SR, Without this, some
	garbage characters would appear in the line on SH7709A.

Index: arch/sh/kernel/time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.5
diff -u -r1.5 time.c
--- arch/sh/kernel/time.c	2000/04/30 23:33:47	1.5
+++ arch/sh/kernel/time.c	2000/05/01 10:35:48
@@ -204,13 +204,6 @@
 static inline void do_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
 	do_timer(regs);
-#ifdef TAKESHI
-	{
-		unsigned long what_is_this=0xa4000124;
-
-		ctrl_outb(ctrl_inb(what_is_this)+1,what_is_this);
-	}
-#endif
 #if 0
 	if (!user_mode(regs))
 		sh_do_profile(regs->pc);
Index: drivers/char/sh-sci.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.c,v
retrieving revision 1.4
diff -u -r1.4 sh-sci.c
--- drivers/char/sh-sci.c	2000/04/15 07:08:02	1.4
+++ drivers/char/sh-sci.c	2000/05/01 10:35:49
@@ -189,10 +189,35 @@
 	ctrl_out(smr_val, SCSMR);
 
 #if defined(CONFIG_SH_SCIF_SERIAL)
+#if defined(__sh3__)
+	{ /* For SH7709, SH7709A, SH7729 */
+		unsigned short data;
+
+		/* We need to set SCPCR to enable RTS/CTS */
+		data = ctrl_inw(SCPCR);
+		/* Clear out SCP7MD1,0, SCP6MD1,0, SCP4MD1,0*/
+		ctrl_outw(data&0x0fcf, SCPCR); 
+	}
+#endif
 	if (C_CRTSCTS(port->gs.tty))
 		fcr_val |= 0x08;
-	else
+	else {
+#if defined(__sh3__)
+		unsigned short data;
+
+		/* We need to set SCPCR to enable RTS/CTS */
+		data = ctrl_inw(SCPCR);
+		/* Clear out SCP7MD1,0, SCP4MD1,0,
+		   Set SCP6MD1,0 = {01} (output)  */
+		ctrl_outw((data&0x0fcf)|0x1000, SCPCR); 
+
+		data = ctrl_inb(SCPDR);
+		/* Set /RTS2 (bit6) = 0 */
+		ctrl_outb(data&0xbf, SCPDR); 
+#elif defined(__SH4__)
 		ctrl_outw(0x0080, SCSPTR); /* Set RTS = 1 */
+#endif
+	}
 	ctrl_out(fcr_val, SCFCR);
 #endif
 
@@ -789,8 +814,8 @@
 	while (!(status & SCI_TD_E));
 
 	ctrl_outb(c, SC_TDR);
+	ctrl_in(SC_SR);		/* Dummy read */
 	ctrl_out(SCI_TD_E_CLEAR, SC_SR);
-
 	restore_flags(flags);
 }
 
@@ -817,6 +842,7 @@
 		}
 	} while (!(status & SCI_RD_F));
 	c = ctrl_inb(SC_RDR);
+	ctrl_in(SC_SR);		/* Dummy read */
 	ctrl_out(SCI_RDRF_CLEAR, SC_SR);
 	restore_flags(flags);
 
Index: drivers/char/sh-sci.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/char/sh-sci.h,v
retrieving revision 1.2
diff -u -r1.2 sh-sci.h
--- drivers/char/sh-sci.h	2000/04/14 17:25:44	1.2
+++ drivers/char/sh-sci.h	2000/05/01 10:35:49
@@ -69,7 +69,10 @@
 #define SC_RDR 0xA400015A
 #define SCFCR  (volatile unsigned char *)0xA400015C
 #define SCFDR  0xA400015E
-#undef  SCSPTR /* Is there any register for RTS?? */
+
+#undef  SCSPTR /* SH7709 doesn't have SCSPTR */
+#define SCPCR  0xA4000116 /* Instead, it has SCPCR and SCPDR */
+#define SCPDR  0xA4000136
 #undef  SCLSR
 
 #define SCSCR_INIT	0x30	/* TIE=0,RIE=0,TE=1,RE=1 */
@@ -187,8 +190,17 @@
  * -- Greg Banks 27Feb2000
  */
 
+/*
+ * 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__)
-#define PCLK           14745600
+#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

Re: [linuxsh-dev] Today's addition

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

Hello Niibe-San and everybody

NIIBE Yutaka wrote:

> To compare the behavior (of SH-4), I worked for SH7709A (in the
> office).  It's another SolutionEngine.  It also failed with RAMDISK
> support (like SH-4).
>
> In my home, SH7708 works fine (with no RAMDISK), RAMDISK may be the
> cause.

Speaking of which ... I don't know if it has anything to do with it but there it goes
:

I've been working on getting the 2.3.99-pre? kernels going on Hypercom's
"WindowsCE ICE" board (which is a flavor of the P2 board from Hitachi, I understand)
for some time now : this board has a 7707 and 16M of RAM.

I had to do some modifications to the ramdisk (and the SCI and tty drivers) to get the
kernel to boot and use the SCI as initial terminal on this board :

1) In the ramdisk : it appears that the following lines in drivers/block/rd.c panic
the kernel when the kernel tries to mount the initrd filesystem :

--8<--8<--SNIP-SNIP--8<--8<--
 /*
  * Immunize device against invalidate_buffers() and prune_icache().
  */
 if (rd_inode[DEVICE_NR(inode->i_rdev)] == NULL) {
  if (!inode->i_bdev) return -ENXIO;
  if ((rd_inode[DEVICE_NR(inode->i_rdev)] = igrab(inode)) != NULL)
   atomic_inc(&rd_inode[DEVICE_NR(inode->i_rdev)]->i_bdev->bd_openers);
 }
--8<--8<--SNIP-SNIP--8<--8<--

If I comment out these lines, the ramdisk works just fine. They seem to have been
added to the kernel fairly recently so I doubt they have been exercised a lot yet.

2) In drivers/char/tty_io.c : the SCI driver doesn't get registered when trying to use
it as initial console, so I had to add several lines to get it registered explicitely.
Here is the patch :

--8<--8<--SNIP-SNIP--8<--8<--
diff -ruN linux_ORIG/drivers/char/tty_io.c linux_PATCHED/drivers/char/tty_io.c
--- linux_ORIG/drivers/char/tty_io.c Tue Mar 21 14:04:53 2000
+++ linux_PATCHED/drivers/char/tty_io.c Fri Mar 31 16:13:53 2000
@@ -141,6 +141,11 @@
 #ifdef CONFIG_SX
 extern int sx_init (void);
 #endif
+#ifdef CONFIG_SH_SCI_SERIAL
+extern int sci_init (void);
+#endif
 #if defined(CONFIG_MVME162_SCC) || defined(CONFIG_BVME6000_SCC) ||
defined(CONFIG_MVME147_SCC)
 extern int vme_scc_init (void);
 extern long vme_scc_console_init(void);
@@ -2317,6 +2322,11 @@
 #ifdef CONFIG_SX
  sx_init();
 #endif
+#ifdef CONFIG_SH_SCI_SERIAL
+sci_init();
+#endif
 #ifdef CONFIG_RIO
  rio_init();
 #endif
--8<--8<--SNIP-SNIP--8<--8<--

3) In driver/char/sh-sci.c and driver/char/sh-sci.h : the driver assumes a bus clock
speed of 14 Mhz. The board I'm working on has a bus clock speed of 30 Mhz, which
changes all the timing values for the SCI clock. So, I modified the table and the code
to use both timing counter values and clock sources, so that the range of baudrates is
higher. Also, I've added a small bit of code to set the baud rate in
serial_console_setup(), otherwise the baud rate is not set when using the SCI as
initial console. Here is the diff :

--8<--8<--SNIP-SNIP--8<--8<--
diff -ruN linux_ORIG/drivers/char/sh-sci.c linux_PATCHED/drivers/char/sh-sci.c
--- linux_ORIG/drivers/char/sh-sci.c Mon May  1 10:55:09 2000
+++ linux_PATCHED/drivers/char/sh-sci.c Tue Apr 25 10:18:00 2000
@@ -115,37 +115,73 @@
 static void sci_set_baud(struct sci_port *port)
 {
  int t;
+/*PPC*/ int cks;

  switch (port->gs.baud) {
  case 0:
   t = -1;
   break;
+/*PPC*/
+ case 110:
+  t = BPS_110;
+  cks = CKS_BPS_110;
+  break;
+ case 150:
+  t = BPS_150;
+  cks = CKS_BPS_150;
+  break;
+ case 300:
+  t = BPS_300;
+  cks = CKS_BPS_300;
+  break;
+ case 600:
+  t = BPS_600;
+  cks = CKS_BPS_600;
+  break;
+ case 1200:
+  t = BPS_1200;
+  cks = CKS_BPS_1200;
+  break;
+/*\PPC*/
  case 2400:
   t = BPS_2400;
+/*PPC*/  cks = CKS_BPS_2400;
   break;
  case 4800:
   t = BPS_4800;
+/*PPC*/  cks = CKS_BPS_4800;
   break;
  case 9600:
   t = BPS_9600;
+/*PPC*/  cks = CKS_BPS_9600;
   break;
  case 19200:
   t = BPS_19200;
+/*PPC*/  cks = CKS_BPS_19200;
   break;
  case 38400:
   t = BPS_38400;
+/*PPC*/  cks = CKS_BPS_38400;
+  break;
+/*PPC*/
+ case 57600:
+  t = BPS_57600;
+  cks = CKS_BPS_57600;
   break;
+/*\PPC*/
  default:
   printk(KERN_INFO "sci: unsupported baud rate: %d, use 115200 instead.\n",
port->gs.baud);
  case 115200:
   t = BPS_115200;
+/*PPC*/  cks = CKS_BPS_115200;
   break;
  }

  if (t > 0) {
   sci_setsignals (port, 1, -1);
   if(t >= 256) {
-   ctrl_out((ctrl_in(SCSMR) & ~3) | 1, SCSMR);
+/*PPC   ctrl_out((ctrl_in(SCSMR) & ~3) | 1, SCSMR);*/
+/*PPC*/   ctrl_out((ctrl_in(SCSMR) & ~3) | cks, SCSMR);
    t >>= 2;
   }
   ctrl_outb(t, SCBRR);
@@ -659,8 +695,10 @@
  sci_driver.type = TTY_DRIVER_TYPE_SERIAL;
  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;
+/*PPC sci_driver.init_termios.c_cflag =*/
+/*PPC  B115200 | CS8 | CREAD | HUPCL | CLOCAL | CRTSCTS;*/
+/*PPC*/ sci_driver.init_termios.c_cflag =
+/*PPC*/  SCI_DEFAULT_SPEED | CS8 | CREAD | HUPCL | CLOCAL;
  sci_driver.flags = TTY_DRIVER_REAL_RAW;
  sci_driver.refcount = &sci_refcount;
  sci_driver.table = sci_table;
@@ -747,6 +785,7 @@
 #ifdef CONFIG_DEBUG_KERNEL_WITH_GDB_STUB
  gdb_detach();
 #endif
+/*PPC*/ printk(KERN_ERR "SCI serial driver registered (major 4)\n");
  return 0;  /* Return -EIO when not detected */
 }

@@ -922,7 +961,8 @@
  */
 static int __init serial_console_setup(struct console *co, char *options)
 {
- int baud = 115200;
+/*PPC int baud = 115200;*/
+/*PPC*/ int baud = SCI_DEFAULT_SPEED_VAL;
  int bits = 8;
  int parity = 'n';
  int cflag = CREAD | HUPCL | CLOCAL;
@@ -978,6 +1018,19 @@
  co->cflag = cflag;

  /* XXX: set baud, char, and parity here. */
+/*PPC*/
+ {
+   struct termios termios;
+   struct tty_struct tty;
+   struct sci_port port;
+
+   termios.c_cflag=cflag;
+   port.gs.baud=baud;
+   tty.termios=&termios;
+   port.gs.tty=&tty;
+   sci_set_termios_cflag(&port);
+ }
+/*\PPC*/
  return 0;
 }

diff -ru linux_ORIG/drivers/char/sh-sci.h linux_PATCHED/drivers/char/sh-sci.h
--- linux_ORIG/drivers/char/sh-sci.h Mon May  1 10:55:33 2000
+++ linux_PATCHED/drivers/char/sh-sci.h Tue Apr 25 14:18:29 2000
@@ -9,6 +9,9 @@
  */
 #include <linux/config.h>

+/*PPC*/ #define SCI_DEFAULT_SPEED B9600
+/*PPC*/ #define SCI_DEFAULT_SPEED_VAL 9600
+
 #if defined(CONFIG_SH_SCI_SERIAL)
 #if defined(__sh3__)
 #define SCSMR  (volatile unsigned char *)0xfffffe80
@@ -28,7 +31,8 @@
 #define SCSPTR 0xffe0001c
 #endif

-#define SCSCR_INIT 0x30 /* TIE=0,RIE=0,TE=1,RE=1 */
+/*PPC #define SCSCR_INIT 0x30 *//* TIE=0,RIE=0,TE=1,RE=1 */
+/*PPC*/ #define SCSCR_INIT 0x31 /* TIE=0,RIE=0,TE=1,RE=1,CKE1=0,CKE0=1*/

 #define SCI_TD_E  0x80
 #define SCI_RD_F  0x40
@@ -187,7 +191,7 @@
  * -- Greg Banks 27Feb2000
  */

-#if defined(__sh3__)
+/*PPC #if defined(__sh3__)
 #define PCLK           14745600
 #elif defined(__SH4__)
 #define PCLK           33333333
@@ -199,4 +203,33 @@
 #define BPS_9600       SCBRR_VALUE(9600)
 #define BPS_19200      SCBRR_VALUE(19200)
 #define BPS_38400      SCBRR_VALUE(38400)
-#define BPS_115200     SCBRR_VALUE(115200)
+#define BPS_115200     SCBRR_VALUE(115200)*/
+
+/* PPC : This table is made from the Hitachi 7707 hardware manual.
+   It assumes
+   a bus clock of 30Mhz. It also specifies the clock source so that we can use
+   a greater range of baudrates */
+#define BPS_110        132
+#define CKS_BPS_110    3
+#define BPS_150        97
+#define CKS_BPS_150    2
+#define BPS_300        194
+#define CKS_BPS_300    2
+#define BPS_600        97
+#define CKS_BPS_600    2
+#define BPS_1200       194
+#define CKS_BPS_1200   1
+#define BPS_2400       97
+#define CKS_BPS_2400   1
+#define BPS_4800       194
+#define CKS_BPS_4800   0
+#define BPS_9600       97
+#define CKS_BPS_9600   0
+#define BPS_19200      48
+#define CKS_BPS_19200  0
+#define BPS_38400      23
+#define CKS_BPS_38400  0
+#define BPS_57600      15
+#define CKS_BPS_57600  0
+#define BPS_115200     7
+#define CKS_BPS_115200 0
--8<--8<--SNIP-SNIP--8<--8<--

Ideally, I think it'd be good to have an option in the .config to set the bus clock
speed and have several tables defined and selected with #ifdefs.

I don't know if any of the above will help anyone but I thought I might share my
findings.

Now for the plea for help :-) :

I assume everybody on the list has userland programs compiled dynamically and running
good on their boards. For some reason, I can run programs that have been compiled
statically against glibc just fine, but I can't run dynamically linked programs
because ld.so segfaults (I use Kaz' latest patch for glibc). What happens is that
ld.so starts, and eventually the function elf_machine_rela() (in
sysdeps/sh/sh3/dl-machine.h) is called during the initial relocation from _dl_start()
and the segfault occurs when the code tries (I think) to poke a fixed-up address in
the code section (which is read-only) instead of the GOT (which is read-write).

I believe it's a linker problem, but I'm no expert with ld.so nor ld so I'm having
hard times figuring out what's wrong. Anybody out there has a clue what the problem
might be ? I have traces of ld.so's startup and other informations relevant to the
problem if you think it'd be helpful.

Thanks in advance.
Take care

[BTW, you guys are doing a tremendous job with the LinuxSH project ! well done !]

---
Pierre-Philippe Coupard <pi...@li...>
Software Engineer, Lineo, Inc.
801-426-5001 x 208
---

Re: [linuxsh-dev] Today's addition

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

Hi

> ld.so starts, and eventually the function elf_machine_rela() (in
> sysdeps/sh/sh3/dl-machine.h) is called during the initial relocation
> from _dl_start() and the segfault occurs when the code tries (I think)
> to poke a fixed-up address in the code section (which is read-only)
> instead of the GOT (which is read-write).
> 
> I believe it's a linker problem, but I'm no expert with ld.so nor ld so
> I'm having hard times figuring out what's wrong. Anybody out there has
> a clue what the problem might be ? I have traces of ld.so's startup and
> other informations relevant to the problem if you think it'd be helpful.

Can you please give us the result of readelf -r ld.so? It shows
relocations of ld.so.
I imagine that your ld.so has .rela.text and the relocation
R_SH_DIR32 or so. It needs the modification of .text segment
of ld.so and becomes the cause of fail as you describe.
Ordinary this type of relocation isn't problem at all since
ld.so will modify the .text segment of the ELF object using
mprotect. But in the bootstrap of ld.so, there is not working
ld.so yet :-)

I want to know also which version of toolchain and their patch
do you use. Niibe-san's visibility patchs for gcc/binutils may
solve your problem. Please check
 ftp://ftp.m17n.org/pub/linux-sh/binutils-000218-000219.diff.gz
and
 ftp://ftp.m17n.org/pub/linux-sh/gcc-symbol-vis-000219.diff.gz

	kaz

[linuxsh-dev] ld.so relocations

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

Hello Kaz,

Thanks for your answer, it is much appreciated

kaz Kojima wrote:

> Can you please give us the result of readelf -r ld.so? It shows
> relocations of ld.so.

Sure. Here it goes :

--8<--8<--SNIP-SNIP--8<--8<--
Relocation section '.rela.text' at offset 0x1710 contains 15 entries:
  Offset    Info  Type            Symbol's Value  Symbol's Name
Addend
  00003288  000a5 R_SH_RELATIVE
00010ec0
  00006294  000a5 R_SH_RELATIVE
00010faa
  00007b98  000a5 R_SH_RELATIVE
00010faa
  00007fdc  000a5 R_SH_RELATIVE
00010faa
  00008208  000a5 R_SH_RELATIVE
00010faa
  00008558  000a5 R_SH_RELATIVE
00010faa
  00008c10  000a5 R_SH_RELATIVE
00010faa
  00008f80  000a5 R_SH_RELATIVE
00010faa
  0000ca3c  000a5 R_SH_RELATIVE
00010faa
  0000cdac  000a5 R_SH_RELATIVE
00010faa
  0000f550  000a5 R_SH_RELATIVE
00010ec0
  0000f670  000a5 R_SH_RELATIVE
00010ec0
  00010374  000a5 R_SH_RELATIVE
00010f0c
  00010654  000a5 R_SH_RELATIVE
00010ec0
  00010d50  000a5 R_SH_RELATIVE
00010ec0

Relocation section '.rela.got' at offset 0x17c4 contains 65 entries:
  Offset    Info  Type            Symbol's Value  Symbol's Name
Addend
  00023924  000a5 R_SH_RELATIVE
00001f60
  000239f4  000a5 R_SH_RELATIVE
00010160
  000239f0  000a5 R_SH_RELATIVE
00023890
  00023980  000a5 R_SH_RELATIVE
00023c10
  000239e4  000a5 R_SH_RELATIVE
00023bfc
  00023930  000a5 R_SH_RELATIVE
00023c24
  00023988  000a5 R_SH_RELATIVE
00023e58
  00023934  000a5 R_SH_RELATIVE
00023e5c
  00023920  000a5 R_SH_RELATIVE
0000b660
  00023950  000a5 R_SH_RELATIVE
00023e64
  00023984  000a5 R_SH_RELATIVE
00023e6c
  000239d0  000a5 R_SH_RELATIVE
00023898
  000239e8  000a5 R_SH_RELATIVE
0000dbc0
  00023998  000a5 R_SH_RELATIVE
00023e78
  0002399c  000a5 R_SH_RELATIVE
00023e7c
  00023914  000a5 R_SH_RELATIVE
00023e88
  000239b4  000a5 R_SH_RELATIVE
0000b0e0
  00023944  000a5 R_SH_RELATIVE
00023e90
  0002392c  000a5 R_SH_RELATIVE
00023e98
  00023978  000a5 R_SH_RELATIVE
00023e9c
  000239b0  000a5 R_SH_RELATIVE
0000b140
  00023940  000a5 R_SH_RELATIVE
00001ee0
  0002394c  000a5 R_SH_RELATIVE
00023ea4
  00023958  000a5 R_SH_RELATIVE
000135c4
  0002397c  000a5 R_SH_RELATIVE
00023eb0
  00023a00  000a5 R_SH_RELATIVE
00010780
  000239fc  000a5 R_SH_RELATIVE
000107a0
  0002398c  000a5 R_SH_RELATIVE
00023894
  000239f8  000a5 R_SH_RELATIVE
00023eb8
  000239e0  000a5 R_SH_RELATIVE
00023ef4
  00023970  000a5 R_SH_RELATIVE
00023ebc
  000239ec  000a5 R_SH_RELATIVE
0002389c
  000239a8  000a5 R_SH_RELATIVE
0001216c
  00023928  000a5 R_SH_RELATIVE
00023ec0
  000239d4  000a5 R_SH_RELATIVE
00023ecc
  000239d8  000a5 R_SH_RELATIVE
00023ed0
  00023948  000a5 R_SH_RELATIVE
00023ee8
  000239ac  000a5 R_SH_RELATIVE
00023864
  000239a4  000a5 R_SH_RELATIVE
00023ef0
  000239c4  011a3 R_SH_GLOB_DAT         00023c04  __libc_internal_tsd_set   +
0
  00023a08  015a3 R_SH_GLOB_DAT         00000000  __pthread_mutex_lock      +
0
  0002396c  016a3 R_SH_GLOB_DAT         00023c08  _dl_profile_output        +
0
  00023910  017a3 R_SH_GLOB_DAT         00023c0c  __libc_stack_end          +
0
  00023994  018a3 R_SH_GLOB_DAT         00023888  _dl_debug_fd              +
0
  00023964  019a3 R_SH_GLOB_DAT         00023c14  _dl_initial_searchlist    +
0
  000239a0  01ea3 R_SH_GLOB_DAT         00023e50  _dl_platformlen           +
0
  00023974  020a3 R_SH_GLOB_DAT         00023e54  _dl_debug_impcalls        +
0
  00023a04  021a3 R_SH_GLOB_DAT         00000000  __pthread_mutex_init      +
0
  0002395c  026a3 R_SH_GLOB_DAT         00023e60  _dl_profile               +
0
  000239b8  028a3 R_SH_GLOB_DAT         00023e70  _dl_global_scope_alloc    +
0
  00023954  02aa3 R_SH_GLOB_DAT         00023e74  __libc_enable_secure      +
0
  00023960  02ca3 R_SH_GLOB_DAT         00023e80  _dl_global_scope          +
0
  000239c0  02da3 R_SH_GLOB_DAT         00023e8c  __libc_internal_tsd_get   +
0
  00023a10  02fa3 R_SH_GLOB_DAT         00000000  __pthread_mutex_unlock    +
0
  0002393c  032a3 R_SH_GLOB_DAT         00023e94  _dl_lazy                  +
0
  000239cc  033a3 R_SH_GLOB_DAT         0000b780  _dl_debug_state           +
0
  00023a0c  035a3 R_SH_GLOB_DAT         00000000  __pthread_mutex_destroy   +
0
  00023918  038a3 R_SH_GLOB_DAT         00023ea0  _dl_main_searchlist       +
0
  00023990  03ea3 R_SH_GLOB_DAT         00023eac  _dl_origin_path           +
0
  0002391c  042a3 R_SH_GLOB_DAT         00023eb4  _dl_starting_up           +
0
  000239bc  044a3 R_SH_GLOB_DAT         0000ca70  _dl_mcount                +
0
  000239dc  047a3 R_SH_GLOB_DAT         00023830  _dl_fpu_control           +
0
  00023938  048a3 R_SH_GLOB_DAT         00023ec4  _dl_loaded                +
0
  00023968  04aa3 R_SH_GLOB_DAT         00023ec8  _dl_profile_map           +
0
  000239c8  04ca3 R_SH_GLOB_DAT         00023ed4  _r_debug                  +
0

Relocation section '.rela.plt' at offset 0x1ad0 contains 25 entries:
  Offset    Info  Type            Symbol's Value  Symbol's Name
Addend
  000238ac  015a4 R_SH_JMP_SLOT         00000000  __pthread_mutex_lock      +
0
  000238b0  01ba4 R_SH_JMP_SLOT         0000cdc0  _dl_sysdep_start          +
0
  000238b4  021a4 R_SH_JMP_SLOT         00000000  __pthread_mutex_init      +
0
  000238b8  022a4 R_SH_JMP_SLOT         0000d990  malloc                    +
0
  000238bc  025a4 R_SH_JMP_SLOT         000082c0  _dl_lookup_versioned_symb +
0
  000238c0  02ba4 R_SH_JMP_SLOT         00007920  _dl_lookup_symbol         +
0
  000238c4  02ea4 R_SH_JMP_SLOT         0000daa0  calloc                    +
0
  000238c8  02fa4 R_SH_JMP_SLOT         00000000  __pthread_mutex_unlock    +
0
  000238cc  033a4 R_SH_JMP_SLOT         0000b780  _dl_debug_state           +
0
  000238d0  034a4 R_SH_JMP_SLOT         00005060  _dl_dst_substitute        +
0
  000238d4  035a4 R_SH_JMP_SLOT         00000000  __pthread_mutex_destroy   +
0
  000238d8  037a4 R_SH_JMP_SLOT         0000b550  _dl_init_next             +
0
  000238dc  039a4 R_SH_JMP_SLOT         0000db20  realloc                   +
0
  000238e0  03aa4 R_SH_JMP_SLOT         0000c1f0  _dl_check_all_versions    +
0
  000238e4  03ba4 R_SH_JMP_SLOT         0000b730  _dl_debug_initialize      +
0
  000238e8  03fa4 R_SH_JMP_SLOT         0000c250  _dl_start_profile         +
0
  000238ec  040a4 R_SH_JMP_SLOT         00009460  _dl_relocate_object       +
0
  000238f0  041a4 R_SH_JMP_SLOT         00004f50  _dl_dst_count             +
0
  000238f4  043a4 R_SH_JMP_SLOT         000078d0  _dl_unload_cache          +
0
  000238f8  045a4 R_SH_JMP_SLOT         0000b880  _dl_debug_message         +
0
  000238fc  046a4 R_SH_JMP_SLOT         000070c0  _dl_map_object            +
0
  00023900  049a4 R_SH_JMP_SLOT         0000b190  _dl_signal_error          +
0
  00023904  04da4 R_SH_JMP_SLOT         0000b380  _dl_catch_error           +
0
  00023908  04ea4 R_SH_JMP_SLOT         0000daf0  free                      +
0
  0002390c  04fa4 R_SH_JMP_SLOT         0000a460  _dl_map_object_deps       +
0
--8<--8<--SNIP-SNIP--8<--8<--

> I imagine that your ld.so has .rela.text and the relocation
> R_SH_DIR32 or so. It needs the modification of .text segment
> of ld.so and becomes the cause of fail as you describe.

Sounds pretty much like the problem I have

> Ordinary this type of relocation isn't problem at all since
> ld.so will modify the .text segment of the ELF object using
> mprotect. But in the bootstrap of ld.so, there is not working
> ld.so yet :-)

That would explain :) From what I have been able to gather (and understand),
offsets are extracted out of the relocation table, added to the load address
and a new fixed-up value is simply written to it (which fails). There is
nothing fancy there.

> I want to know also which version of toolchain and their patch

I use :

- binutils-000218 with the binutils-000205 SH patch and the modifications by
hand described in Jerome's FAQ. My target name is "sh-pc-linux-gnu" and your
PIC patches for SH (binutils-000123-000131 if I remember correctly). I had to
patch some things by hand because of syntax changes between binutils 000205
and 000218.

- gcc-core 2.95.2 with the gcc-2.95.2-000203 SH patch and
gcc-2.95.2-symbol-vis-000205 patch. Again, my target name is
"sh-pc-linux-gnu"

The kernel compiles and works dandy with these tools, and so do statically
linked programs and the bootloader I created for that particular board (and
that I can't disclose unfortunately).

> do you use. Niibe-san's visibility patchs for gcc/binutils may
> solve your problem. Please check
>  ftp://ftp.m17n.org/pub/linux-sh/binutils-000218-000219.diff.gz
> and
>  ftp://ftp.m17n.org/pub/linux-sh/gcc-symbol-vis-000219.diff.gz

I'll give them a try right now !

Thanks,
Take care

---
Pierre-Philippe Coupard <pi...@li...>
Software Engineer, Lineo, Inc.
801-426-5001 x 208
---

Re: [linuxsh-dev] Today's addition

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

Hello Pierre!

Thanks for your feedback.

(1) RAMDISK issue

I'll try that.  Thanks.

(2) Initialization of SCI

I think that this issue is resolved in current kernel (2.3.99-pre6 and
later).  If not, please let us know.

(3) Peripheral clock

 > Ideally, I think it'd be good to have an option in the .config to
 > set the bus clock speed and have several tables defined and
 > selected with #ifdefs.

Yes, that'd be a solution.  Alternatively, we could use the value
measured with RTC.  I'm thinking exporting the variable
sh_periheral_clock and sh_module_clock from time.c.  I know that
current code of time.c is not correct for all the cases, but it works
at least for me.

 > I don't know if any of the above will help anyone but I thought I
 > might share my findings.

Surely, it helps much.  Thank you.

 > Now for the plea for help :-) :

Yes.  Welcome to the development team!!

 > I assume everybody on the list has userland programs compiled
 > dynamically and running good on their boards. For some reason, I
 > can run programs that have been compiled statically against glibc
 > just fine, but I can't run dynamically linked programs because
 > ld.so segfaults (I use Kaz' latest patch for glibc). What happens
 > is that ld.so starts, and eventually the function
 > elf_machine_rela() (in sysdeps/sh/sh3/dl-machine.h) is called
 > during the initial relocation from _dl_start() and the segfault
 > occurs when the code tries (I think) to poke a fixed-up address in
 > the code section (which is read-only) instead of the GOT (which is
 > read-write).

Your description is correct.  I guess that the target label to be
resolved is the one of libgcc.a, isn't it?  Here is the story.

----------------
(a) Libgcc is the library of functions which GCC assumes.  In the case
    of SuperH, division results the function call to libgcc, for
    example.

(b) ld.so is the dynamic loader, it could not depends on other
    libraries, by definition (since it *is* the first entity to be
    loaded and it load other libraries).

(c) In the current setting of GCC and GNU Binutils, there's no
    difference between libgcc and other libraries.  The linker handles
    libgcc as just a library.

[... I forgot the detail, I'll explain later if needed ...]

(z) In the current building process of GNU C library, we unfortunately
    have relocation entries for libgcc.
----------------

There'd be many ways to resolve this issue.  Say, having libgcc shared
library, changing GNU C library building process, and so on.  My trial
is changing GCC so that we can distingush the label of libgcc
functions.  Please get the patch from:
	ftp://ftp.m17n.org/pub/super-h/gcc-symbol-vis-000501.diff.gz

It's agains the Kaz' patch of gcc-2.95.2-000228.

WARNING: This is just a experimental hack.  This may not included
standard distribution of GCC, since I did this hack without seeing the
proposed-but-not-yet-released gABI, guess(and expect)ing the feature.

With this patch, you don't see the entries on ld.so.  Again, this may
be work around, not the solution.  We have to think hard, more...

Please let me know how this works (or not) for you, if you will try.
-- 
Niibe Yutaka

Re: [linuxsh-dev] Today's addition

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

Hello Niibe,

NIIBE Yutaka wrote:

> Hello Pierre!
>
> Thanks for your feedback.
>
> (1) RAMDISK issue
>
> I'll try that.  Thanks.
>
> (2) Initialization of SCI
>
> I think that this issue is resolved in current kernel (2.3.99-pre6 and
> later).  If not, please let us know.

I was working on pre5 but I'll upgrade and give it a try.

> (3) Peripheral clock
>
>  > Ideally, I think it'd be good to have an option in the .config to
>  > set the bus clock speed and have several tables defined and
>  > selected with #ifdefs.
>
> Yes, that'd be a solution.  Alternatively, we could use the value
> measured with RTC.  I'm thinking exporting the variable
> sh_periheral_clock and sh_module_clock from time.c.  I know that
> current code of time.c is not correct for all the cases, but it works
> at least for me.

I have to carry my modifications to the kernel to pre6 then I'll make
entries in the SH defconfigs. It'll be a solution until something nicer
is done, but I don't think it's too critical.

>  > I don't know if any of the above will help anyone but I thought I
>  > might share my findings.
>
> Surely, it helps much.  Thank you.
>
>  > Now for the plea for help :-) :
>
> Yes.  Welcome to the development team!!
>
>  > I assume everybody on the list has userland programs compiled
>  > dynamically and running good on their boards. For some reason, I
>  > can run programs that have been compiled statically against glibc
>  > just fine, but I can't run dynamically linked programs because
>  > ld.so segfaults (I use Kaz' latest patch for glibc). What happens
>  > is that ld.so starts, and eventually the function
>  > elf_machine_rela() (in sysdeps/sh/sh3/dl-machine.h) is called
>  > during the initial relocation from _dl_start() and the segfault
>  > occurs when the code tries (I think) to poke a fixed-up address in
>  > the code section (which is read-only) instead of the GOT (which is
>  > read-write).
>
> Your description is correct.  I guess that the target label to be
> resolved is the one of libgcc.a, isn't it?  Here is the story.
>

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

> Please let me know how this works (or not) for you, if you will try.

Wow, now that's indepth knowledge :)
I will certainly try and let you know my results.

Thank you very much,
Take care

---
Pierre-Philippe Coupard <pi...@li...>
Software Engineer, Lineo, Inc.
801-426-5001 x 208
---

Re: [linuxsh-dev] Today's addition

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

Hello Niibe,

NIIBE Yutaka wrote:

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

> functions.  Please get the patch from:
>         ftp://ftp.m17n.org/pub/super-h/gcc-symbol-vis-000501.diff.gz
>
> It's agains the Kaz' patch of gcc-2.95.2-000228.
>
> WARNING: This is just a experimental hack.  This may not included
> standard distribution of GCC, since I did this hack without seeing the
> proposed-but-not-yet-released gABI, guess(and expect)ing the feature.
>
> With this patch, you don't see the entries on ld.so.  Again, this may
> be work around, not the solution.  We have to think hard, more...
>
> Please let me know how this works (or not) for you, if you will try.

It works ! ld.so compiles and runs fine now. Unfortunately, the new
visibility patch seems to break the linking of some other parts of glibc,
but now that I know what to look for, I can play around to fix the
problem :-)

Thanks a lot to you and Kaz,
Take care

---
Pierre-Philippe Coupard <pi...@li...>
Software Engineer, Lineo, Inc.
801-426-5001 x 208
---