linuxsh-dev

RE: [linuxsh-dev] problem with GDB

[Studencki P. <Paw...@er...>]

Hello,

Greg and Jeremy, I want to thank You for help :)
Your tips were very useful! Now I'm able to load my kernel. I didn't know,
that loading process needs so much time :))

regards
Pawel

Re: [linuxsh-dev] problem with GDB

[Greg B. <gb...@po...>]

Studencki Pawel wrote:
> 
> Hello,
> 
> I try to debug linux on my development board(EBX7709) with GDB. It's a
> SH7709. I had problems to adapt sh-stub to my board, so I've used a part of
> WinCE bootloader in function "init_bsc"

  This is the hardest part of porting sh-ipl.  It took us several attempts
and a couple of months to get it completely correct, even with all possible
assistance from the hardware vendor.

> and modified config.h, config.mk,
> Makefile and machine/ebx.mem (for my board) The problem is, sh-stub doesn't
> start alone, direct from flash memory...So I start winCe bootloader, which
> starts gdb-stub, it's temporary solution probably, but it works.

  Yep, we did something like this for quite a while.

> I can see initial messages from GDB and when I press 'g' he replayes with a
> correct string. Problems are coming, when I break kermit and start GDB
> client. GDB loads only two sections and that's all. had somebody a similar
> problem? Is it problem with memory configuration of sh-stub?
> 
> file: machine/ebx.mem looks like:
> MEMORY
> {
>         ROM (rx):   ORIGIN = 0x80800000, LENGTH = 16M
>         RAM (rw):   ORIGIN = 0x8c000000, l = 16M
>         STACK (rw): ORIGIN = 0x8c010000, LENGTH =  4096
> }


  I see three problems with this.

1.  Your RAM and STACK sections overlap, which is bad in general
    (although here the overlap is outside the part of the RAM section
     which sh-ipl uses).

2.  Your RAM and STACK collide with where the kernel will be loaded,
    which is fatal.

3.  Your addresses are 0x8xxxxxxx instead of 0xaxxxxxxx.

  Your memory map should look like this:

ac000000 sh-ipl RAM
ac000a00 sh-ipl STACK
ac001000 kernel (empty page)
ac002000 kernel entry point

  I suggest you try a .mem file like this:

MEMORY
{
        ROM (rx):   ORIGIN = 0xa0800000, LENGTH = 1024k
        RAM (rw):   ORIGIN = 0xac000000, LENGTH = 2560
        STACK (rw): ORIGIN = 0xac000a00, LENGTH = 1536
}

  Remember, the sections "ROM" and "RAM" don't have to describe the entirety
of the platform's memory, they just have to allocate readonly and readwrite
areas of memory for the linker to allocate code and data into.


Greg
-- 
These are my opinions not PPIs.

[linuxsh-dev] Question on SH/kernel discrepancies

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

Jeremy Siegel wrote:
 > We've been considering SH support in future distributions, and I've
 > noticed a couple differences between the SourceForge CVS and kernel.org
 > in non-SH-specific areas.  In particular:
 > 
 >   - In mm/memory.c:do_swap_page(), a pair of page/cache flush calls were
 > 
 >     moved out of an "if (!page)" block down toward the function end, so
 >     they are executed in more cases and at a different time.  This
 >     change was apparently put into the SH CVS source at version 1.7
 >     nearly 6 months ago, but isn't in kernel.org v2.4.1.  I'm not that
 >     familiar with the memory-management internals for linux (or SH); is
 >     this something that SH requires, or is it a "leftover" artifact of
 >     earlier cache/MMU testing?  If it's needed, is there some reason why
 > 
 >     it has been rejected by the main linux tree?

I believe it's needed for SH-4.  SH-4 has virtually indexed and
physically tagged cache system with write back.  For such architecture
the changes are required.

I've reported two times last summer, but got no interest.  Nowadays,
we have bugzilla for linux-mm, I will report it again.

 >   - In driver/ide/ide.c:ide_wait_cmd(), the SH code includes a delay
 >     immediately before function return.  Again, is this required for the
 > 
 >     SH, or is it leftover test/debug code?

IIRC, it is required for Hitachi SolutionEngine only.  It's kinda of
artifact, which should be removed (when some work around is found).
-- 

[linuxsh-dev] Question on SH/kernel discrepancies

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

Hello,

We've been considering SH support in future distributions, and I've
noticed a couple differences between the SourceForge CVS and kernel.org
in non-SH-specific areas.  In particular:

  - In mm/memory.c:do_swap_page(), a pair of page/cache flush calls were

    moved out of an "if (!page)" block down toward the function end, so
    they are executed in more cases and at a different time.  This
    change was apparently put into the SH CVS source at version 1.7
    nearly 6 months ago, but isn't in kernel.org v2.4.1.  I'm not that
    familiar with the memory-management internals for linux (or SH); is
    this something that SH requires, or is it a "leftover" artifact of
    earlier cache/MMU testing?  If it's needed, is there some reason why

    it has been rejected by the main linux tree?

  - In driver/ide/ide.c:ide_wait_cmd(), the SH code includes a delay
    immediately before function return.  Again, is this required for the

    SH, or is it leftover test/debug code?

Thanks In Advance for any insights!

--Jeremy Siegel
   js...@mv...

[linuxsh-dev] ST40STB1 changes

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

Folks

I've just checked in a bundle of changes which add support for the
ST40STB1 (which is the first SH4 variant from STMicroelectronics) and
the corrisponding boards (HARP and Overdrive).

Most of the changes are simply adding STB1 where there is a list of
devices, and new board/chip specific files, but there are a few other
changes which you may (hopefully not) need to be aware of:

 - I've added a 'shift' parameter to the HD64465 I/O address mapping
   functions.  This was needed to allow the standard 16550 serial
   driver to work with the serial port on the HD64465.

 - I fixed what appears to be be a problem in the RTC handling of
   1/128 second register.

 - In the SCI code I've moved the interrupt installation code from when
   the driver is initialised to when it is opened for the first time. This
   allows the SCI to be used by another driver when not needed for a TTY.

 - A reworking of the way NR_IRQ is calculated to make it easier to expand.

A more complete list of changes is in the ChangeLog.

Hopefully I've not broken anything, but please let me know if you have
any problems.

Stuart

[linuxsh-dev] problem with GDB

[Studencki P. <Paw...@er...>]

Hello,

I try to debug linux on my development board(EBX7709) with GDB. It's a
SH7709. I had problems to adapt sh-stub to my board, so I've used a part of
WinCE bootloader in function "init_bsc" and modified config.h, config.mk,
Makefile and machine/ebx.mem (for my board) The problem is, sh-stub doesn't
start alone, direct from flash memory...So I start winCe bootloader, which
starts gdb-stub, it's temporary solution probably, but it works.
I can see initial messages from GDB and when I press 'g' he replayes with a
correct string. Problems are coming, when I break kermit and start GDB
client. GDB loads only two sections and that's all. had somebody a similar
problem? Is it problem with memory configuration of sh-stub?

file: machine/ebx.mem looks like:
MEMORY
{
        ROM (rx):   ORIGIN = 0x80800000, LENGTH = 16M
        RAM (rw):   ORIGIN = 0x8c000000, l = 16M
        STACK (rw): ORIGIN = 0x8c010000, LENGTH =  4096
}   

Flash memory start 0x80800000(second part, where sh-stub has been burned),
length 16M (all flash mem)
RAM 16M



and here are GDB messages (baud and line settings are in .gdbinit):

-------------------------------------------------------------------------
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=sh-unknown-linux-gnu"...
0x808019d6 in ?? ()
Loading section .empty_zero_page, size 0x1000 lma 0x8c001000
Loading section .text, size 0x99cec lma 0x8c002000
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
--------------------------------------------------------------------------


thanks for any suggestions
Pawel

Re: [linuxsh-dev] Bootloader

[Greg B. <gb...@po...>]

Jeff Brubaker wrote:
> 
>         I have a cassiopeia A-11. This runs windows ce 1.0. The bootloader
> list on the web page says that 2.0 is needed, or else the bootloader needs
> to be compiled with the Windows 1.0 CE SDK. I am a subscriber to MSDN
> Universal, and should have access to it. I would like to compile it to run
> on Windows CE 1.0.
> 
>         What is the name Microsoft's overstaffed marketing department come
> up with to call the windows CE SDK? Hopefully they still have it.
> They conveinently discontinued support for Win CE 1.0 devices in
> activeSync so
> it wouldn't surprise me if they did the same with the SDK.

  Sorry Jeff, I really can't help.  I've never compiled a WinCE program
in my life and look forward to never having to.  The machine I work on
has a flash-based bootloader which is used to boot either WinCE or Linux.
Perhaps someone on the list knows?

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] Bootloader

[Jeff B. <je...@bi...>]

	I have a cassiopeia A-11. This runs windows ce 1.0. The bootloader
list on the web page says that 2.0 is needed, or else the bootloader needs
to be compiled with the Windows 1.0 CE SDK. I am a subscriber to MSDN
Universal, and should have access to it. I would like to compile it to run
on Windows CE 1.0. 

	What is the name Microsoft's overstaffed marketing department come
up with to call the windows CE SDK? Hopefully they still have it. 
They conveinently discontinued support for Win CE 1.0 devices in
activeSync so
it wouldn't surprise me if they did the same with the SDK. 


----
Jeff

[linuxsh-dev] [PATCH] EC3104 update

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

Philipp Rumpf wrote:
 > Obvious-ish updates to the EC3104/Epson 1355 code (as tested on my
 > Aero 8000).  This contains some more debugging/dead code which will
 > be removed once everything's a bit more stable.

Thanks, installed.

Status of current SuperH kernel:

The tool-chain related changes are included in 2.4.1.  There remains:

	* Machine vector interface change
	* Machine dependent code update
	* Drivers update

to be included.
-- 

[linuxsh-dev] [PATCH] EC3104 update

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

Obvious-ish updates to the EC3104/Epson 1355 code (as tested on my
Aero 8000).  This contains some more debugging/dead code which will
be removed once everything's a bit more stable.

	Philipp Rumpf

diff -urNx CVS linuxsh/kernel/arch/sh/kernel/setup_ec3104.c linux-aero/arch/sh/kernel/setup_ec3104.c
--- linuxsh/kernel/arch/sh/kernel/setup_ec3104.c	Mon Dec 25 16:07:13 2000
+++ linux-aero/arch/sh/kernel/setup_ec3104.c	Sat Jan 27 04:40:19 2001
@@ -42,10 +42,32 @@
  *	 8	serial (2)	b0ec8000	b0ec0020	00000100
  *	 9	serial (3)	b0ec9000	b0ec0024	00000200
  *	10	serial (4)	b0eca000	b0ec0028	00000400
+ *	12	GPIO (1)	b0ecc000	b0ec0030
+ *	13      GPIO (2)	b0ecc000	b0ec0030
  *	16	pcmcia (1)	b0ed0000	b0ec0040	00010000
  *	17	pcmcia (2)	b0ed1000	b0ec0044	00020000
  */
 
+/* I used the register names from another interrupt controller I worked with,
+ * since it seems to be identical to the ec3104 except that all bits are
+ * inverted:
+ *
+ * IRR: Interrupt Request Register (pending and enabled interrupts)
+ * IMR: Interrupt Mask Register (which interrupts are enabled)
+ * IPR: Interrupt Pending Register (pending interrupts, even disabled ones)
+ *
+ * 0 bits mean pending or enabled, 1 bits mean not pending or disabled.  all
+ * IRQs seem to be level-triggered.
+ */
+
+#define EC3104_IRR (EC3104_BASE + 0x1000)
+#define EC3104_IMR (EC3104_BASE + 0x1004)
+#define EC3104_IPR (EC3104_BASE + 0x1008)
+
+#define ctrl_readl(addr) (*(volatile u32 *)(addr))
+#define ctrl_writel(data,addr) (*(volatile u32 *)(addr) = (data))
+#define ctrl_readb(addr) (*(volatile u8 *)(addr))
+
 static char *ec3104_name(unsigned index)
 {
 	switch(index) {
@@ -83,26 +105,25 @@
 	}
 }
 
-/* I used the register names from another interrupt controller I worked with,
- * since it seems to be identical to the ec3104 except that all bits are
- * inverted:
- *
- * IRR: Interrupt Request Register (pending and enabled interrupts)
- * IMR: Interrupt Mask Register (which interrupts are enabled)
- * IPR: Interrupt Pending Register (pending interrupts, even disabled ones)
- *
- * 0 bits mean pending or enabled, 1 bits mean not pending or disabled.  all
- * IRQs seem to be level-triggered.
- */
-
-#define EC3104_IRR (EC3104_BASE + 0x1000)
-#define EC3104_IMR (EC3104_BASE + 0x1004)
-#define EC3104_IPR (EC3104_BASE + 0x1008)
-
-#define ctrl_readl(addr) (*(volatile u32 *)(addr))
-#define ctrl_writel(data,addr) (*(volatile u32 *)(addr) = (data))
-#define ctrl_readb(addr) (*(volatile u8 *)(addr))
+int get_pending_interrupts(char *buf)
+{
+	u32 ipr;
+	u32 bit;
+	char *p = buf;
+
+        p += sprintf(p, "pending: (");
+	
+	ipr = ctrl_inl(EC3104_IPR);
+
+	for (bit = 1; bit < 32; bit++)
+		if (!(ipr & (1<<bit)))
+			p += sprintf(p, "%s ", ec3104_name(bit));
+	
+	p += sprintf(p, ")\n");
 
+	return p - buf;
+}
+	
 static inline u32 ec3104_irq2mask(unsigned int irq)
 {
 	return (1 << (irq - EC3104_IRQBASE));
diff -urNx CVS linuxsh/kernel/drivers/char/ec3104_keyb.c linux-aero/drivers/char/ec3104_keyb.c
--- linuxsh/kernel/drivers/char/ec3104_keyb.c	Mon Dec 25 16:07:13 2000
+++ linux-aero/drivers/char/ec3104_keyb.c	Sat Jan 27 04:35:59 2001
@@ -60,10 +60,12 @@
 #define MSR_CTS 0x10
 #define MCR_RTS 0x02
 #define LSR_DR 0x01
+#define LSR_BOTH_EMPTY 0x60
 
-static struct ec3104_keyb_struct {
-	u8 packet[3];
+static struct e5_struct {
+	u8 packet[8];
 	int pos;
+	int length;
 
 	u8 cached_mcr;
 	u8 last_msr;
@@ -192,6 +194,9 @@
 	case 106: /* Fn */
 		/* this is wrong. */
 		return 84;
+
+	default:
+		return 0;
 	}
 }
 		
@@ -222,30 +227,153 @@
 {
 }
 
-static void ec3104_keyb_receive(struct ec3104_keyb_struct *k)
+static u8 e5_checksum(u8 *packet, int count)
+{
+	int i;
+	u8 sum = 0;
+
+	for (i=0; i<count; i++)
+		sum ^= packet[i];
+		
+	if (sum & 0x80)
+		sum ^= 0xc0;
+
+	return sum;
+}
+
+static void e5_wait_for_cts(struct e5_struct *k)
+{
+	u8 msr;
+		
+	do {
+		msr = ctrl_inb(EC3104_SER4_MSR);
+	} while (!(msr & MSR_CTS));
+}
+
+
+static void e5_send_byte(u8 byte, struct e5_struct *k)
+{
+	u8 status;
+		
+	do {
+		status = ctrl_inb(EC3104_SER4_LSR);
+	} while ((status & LSR_BOTH_EMPTY) != LSR_BOTH_EMPTY);
+	
+	printk("<%02x>", byte);
+
+	ctrl_outb(byte, EC3104_SER4_DATA);
+
+	do {
+		status = ctrl_inb(EC3104_SER4_LSR);
+	} while ((status & LSR_BOTH_EMPTY) != LSR_BOTH_EMPTY);
+	
+}
+
+static int e5_send_packet(u8 *packet, int count, struct e5_struct *k)
+{
+	int i;
+
+	disable_irq(EC3104_IRQ_SER4);
+	
+	if (k->cached_mcr & MCR_RTS) {
+		printk("e5_send_packet: too slow\n");
+		enable_irq(EC3104_IRQ_SER4);
+		return -EAGAIN;
+	}
+
+	k->cached_mcr |= MCR_RTS;
+	ctrl_outb(k->cached_mcr, EC3104_SER4_MCR);
+
+	e5_wait_for_cts(k);
+
+	printk("p: ");
+
+	for(i=0; i<count; i++)
+		e5_send_byte(packet[i], k);
+
+	e5_send_byte(e5_checksum(packet, count), k);
+
+	printk("\n");
+
+	udelay(1500);
+
+	k->cached_mcr &= ~MCR_RTS;
+	ctrl_outb(k->cached_mcr, EC3104_SER4_MCR);
+
+	set_current_state(TASK_UNINTERRUPTIBLE);
+	
+	
+
+	enable_irq(EC3104_IRQ_SER4);
+
+	
+
+	return 0;
+}
+
+/*
+ * E5 packets we know about:
+ * E5->host 0x80 0x05 <checksum> - resend packet
+ * host->E5 0x83 0x43 <contrast> - set LCD contrast
+ * host->E5 0x85 0x41 0x02 <brightness> 0x02 - set LCD backlight
+ * E5->host 0x87 <ps2 packet> 0x00 <checksum> - external PS2 
+ * E5->host 0x88 <scancode> <checksum> - key press
+ */
+
+static void e5_receive(struct e5_struct *k)
 {
 	k->packet[k->pos++] = ctrl_inb(EC3104_SER4_DATA);
 
-	/* All E5 packets I've seen look like this:
-	 * 0x88 <scancode> <mystery byte>.  mystery byte seems to depend on the
-	 * key that was pressed only so we ignore it (scancode has all the
-	 * information we need).
-	 */
-
-	if (k->pos == 3) {
-		if (k->packet[0] != 0x88)
-			printk(KERN_WARNING "got bogus EC3104/E5 packet (%02x)\n",
+	if (k->pos == 1) {
+		switch(k->packet[0]) {
+		case 0x80:
+			k->length = 3;
+			break;
+			
+		case 0x87: /* PS2 ext */
+			k->length = 6;
+			break;
+
+		case 0x88: /* keyboard */
+			k->length = 3;
+			break;
+
+		default:
+			k->length = 1;
+			printk(KERN_WARNING "unknown E5 packet %02x\n",
 			       k->packet[0]);
+		}
+	}
 
-		handle_keyboard_event(k->packet[1]);
-		
-		k->pos = 0;
+	if (k->pos == k->length) {
+		int i;
+
+		if (e5_checksum(k->packet, k->length) != 0)
+			printk(KERN_WARNING "E5: wrong checksum\n");
+
+#if 0
+		printk("E5 packet [");
+		for(i=0; i<k->length; i++) {
+			printk("%02x ", k->packet[i]);
+		}
+
+		printk("(%02x)]\n", e5_checksum(k->packet, k->length-1));
+#endif
+
+		switch(k->packet[0]) {
+		case 0x80:
+		case 0x88:
+			handle_keyboard_event(k->packet[1]);
+			break;
+		}
+
+		k->pos = k->length = 0;
 	}
 }
 
 static void ec3104_keyb_interrupt(int irq, void *data, struct pt_regs *regs)
 {
-	struct ec3104_keyb_struct *k = &ec3104_keyb;
+	struct e5_struct *k = &ec3104_keyb;
 	u8 msr, lsr;
 
 	kbd_pt_regs = regs;
@@ -274,12 +402,12 @@
 	lsr = ctrl_inb(EC3104_SER4_LSR);
 
 	if (lsr & LSR_DR)
-		ec3104_keyb_receive(k);
+		e5_receive(k);
 }
 
 static void ec3104_keyb_clear_state(void)
 {
-	struct ec3104_keyb_struct *k = &ec3104_keyb;
+	struct e5_struct *k = &ec3104_keyb;
 	u8 msr, lsr;
 	
 	/* we want CTS to be low */
@@ -293,7 +421,7 @@
 		lsr = ctrl_inb(EC3104_SER4_LSR);
 		
 		if (lsr & LSR_DR) {
-			ec3104_keyb_receive(k);
+			e5_receive(k);
 			continue;
 		}
 
diff -urNx CVS linuxsh/kernel/drivers/video/Config.in linux-aero/drivers/video/Config.in
--- linuxsh/kernel/drivers/video/Config.in	Tue Jan 30 07:15:17 2001
+++ linux-aero/drivers/video/Config.in	Sat Jan 27 04:47:54 2001
@@ -98,7 +98,11 @@
          bool '    CGsix (GX,TurboGX) support' CONFIG_FB_CGSIX
       fi
    fi
-   bool 'Epson 1355 framebuffer support' CONFIG_FB_E1355
+   bool '  Epson 1355 framebuffer support' CONFIG_FB_E1355
+   if [ "$CONFIG_FB_E1355" = "y" ]; then
+      hex '    Register Base Address' CONFIG_E1355_REG_BASE a8000000
+      hex '    Framebuffer Base Address' CONFIG_E1355_FB_BASE a8200000
+   fi
    if [ "$CONFIG_SH_DREAMCAST" = "y" ]; then
       tristate '  Dreamcast Frame Buffer support' CONFIG_FB_DC
    fi
diff -urNx CVS linuxsh/kernel/drivers/video/epson1355fb.c linux-aero/drivers/video/epson1355fb.c
--- linuxsh/kernel/drivers/video/epson1355fb.c	Mon Dec 25 19:02:08 2000
+++ linux-aero/drivers/video/epson1355fb.c	Fri Jan 26 09:41:04 2001
@@ -15,6 +15,7 @@
  * 16 bpp support
  * crt support
  * hw cursor support
+ * SwivelView
  */
 
 #include <asm/io.h>
@@ -38,14 +39,14 @@
 
 #define E1355_PANEL	0x02
 #define E1355_DISPLAY	0x0D
+#define E1355_MISC	0x1B
 #define E1355_GPIO	0x20
 #define E1355_LUT_INDEX 0x24
 #define E1355_LUT_DATA	0x26
 
 #ifdef CONFIG_SUPERH
-/* tell me if your machine has a different base address .. */
-#define E1355_REG_BASE	0xB0000000
-#define E1355_FB_BASE	0xB0200000
+#define E1355_REG_BASE	CONFIG_E1355_REG_BASE
+#define E1355_FB_BASE	CONFIG_E1355_FB_BASE
 
 static inline u8 e1355_read_reg(int index)
 {
@@ -87,16 +88,30 @@
 /* ------------------- chipset specific functions -------------------------- */
 
 
+static void disable_hw_cursor(void)
+{
+	u8 curs;
+
+	curs = e1355_read_reg(0x27);
+	curs &= ~0xc0;
+	e1355_write_reg(curs, 0x27);
+}
+
 static void e1355_detect(void)
 {
 	u8 rev;
 
+	e1355_write_reg(0x00, E1355_MISC);
+
 	rev = e1355_read_reg(0x00);
 
 	if ((rev & 0xfc) != 0x0c) {
 		printk(KERN_WARNING "Epson 1355 not detected\n");
 	}
 
+	/* XXX */
+	disable_hw_cursor();
+
 	e1355_encode_var(&default_var, NULL, NULL);
 }
 
@@ -373,7 +388,7 @@
  * The AERO_HACKS parts disable/enable the backlight on the Compaq Aero 8000.
  * I'm not sure they aren't dangerous to the hardware, so be warned.
  */
-#define AERO_HACKS
+#undef AERO_HACKS
 
 static int e1355_blank(int blank_mode, struct fb_info_gen *info)
 {
@@ -478,19 +493,8 @@
 	return 0;
 }
 
-static void disable_hw_cursor(void)
-{
-	u8 curs;
-
-	curs = e1355_read_reg(0x27);
-	curs &= ~0xc0;
-	e1355_write_reg(curs, 0x27);
-}
-
 int __init e1355fb_init(void)
 {
-	disable_hw_cursor();
-
 	fb_info.gen.fbhw = &e1355_switch;
 	fb_info.gen.fbhw->detect();
 	strcpy(fb_info.gen.info.modename, "SED1355");

[linuxsh-dev] Linux/SH Status and Download questions

[Jeremy S. <jas...@pa...>]

Hi all,

I've been looking at Linux/SH (and these lists) for a while, but am
still relatively new to this arena. The kernel from SourceForge CVS
seems to work for the Hitachi 7708/9/9A and 7750; can anyone tell me if
it (or some other source) has been ported to the 7751 as well? Or if
there are any ports for the SH-3/DSP versions (e.g. 7729 et. al)? (If
there's no code, any particular advice for what to watch out for?)

Also, I've tried the kernel on an SH3 Solution Engine with the Hitachi
monitor, which so far seems fine -- but the "sh-ipl+g" on m17n looks
interesting. Are there notes or a cheat-sheet readily available to save
a bit of time using it?

Thanks in advance for any input...

--Jeremy Siegel

[linuxsh-dev] The Next Yahoo

[<lau...@ex...>]

Hi, linuxsh-dev

What if Yahoo Paid You?  Now a reality!!!

World's First Completely Commissionable Portal just released.

Get paid as thousands search, email, or use any of our services. 14 months and 1.5 
million dollars invested in infrastructure and technology.

We are going after Yahoo!

Imagine getting paid as others use eBay, Expedia, long distance, cellular, insurance, 
and much more.

We have solid long-term contracts with multi-million dollar companies. They are 
knocking down our door to be a part of our amazing viral customer acquisition 
model.

Get your FREE portal today and start making solid income on thousands as they do 
what they normally do on the internet!

Email: lau...@ex...  OR reply to this email.

Include your phone number. We will call you back to let you in on how to get a 
founders position and share the wealth of the web!

We have taken applications for only 1 month now and have already paid out over 
$100,000 in commissions. Get your share!

We are set to have 1 million customers this year and launch globally this summer. This 
is the time millionaires will be made with us!

I look forward to speaking with you.

Trip Wakefield
USA
lau...@ex...

P.S.. I replaced my job income in 3 weeks with our company! We have a simple, 
easy to follow, 3 step system for success!

Be sure to reply with your phone number.



If you do not wish to correspond, reply with "remove" in the subject. Thank You!

Re: [linuxsh-dev] Unaligned access crash in signal handlers

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

SUGIOKA Toshinobu wrote:
 > Currently flush_icache_range uses A-bit. but A-bit works only when
 > ITLB entry exists. UTLB entry should not work.
 > So every I-cache entry should be compared with physical address by hand
 > or all I-cache should be invalidated.

Umm...  I didn't know that.  I've checked the hardware manual, and
you're right.  We need ITLB entry to flush I-cache with A-bit.

While The Right Thing may be fixing flush_icache_range, I'm not sure
about the semantics well, right now.  It seems for me that we don't
need to purge out the I-cache, but just write back D-cache, with newer
scheme (Documentation/cachetlb.txt), but I'm not sure.

Besides, currently, the arguments (START, END) to flush_icache_range
is large one (i.e. mmap ranges) except signal handling, so we need to
re-write the function anyway.

Could you please try this out?  This purges the entry regardless it's
the page mapped or not.

This also includes a bug fix of SH-3 shared page.  X server worked
quite badly in SH-3 implementation because of that.


2001-01-23  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/kernel/signal.c (setup_frame, setup_rt_frame): 
	Use flush_cache_sigtramp.

	* arch/sh/mm/cache.c (flush_cache_sigtramp): Implemented.

	* include/asm-sh/pgtable.h (_PAGE_SHARED): Always _PAGE_U0_SHARED.
	(was conditionally _PAGE_HW_SHARED on SH-3).  With _PAGE_HW_SHARED,
	all processes share the page, while proper semantics is "some
	processes share the page".
	(flush_cache_sigtramp): New function.

Index: arch/sh/kernel/signal.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/signal.c,v
retrieving revision 1.13
diff -u -r1.13 signal.c
--- arch/sh/kernel/signal.c	2000/09/04 06:41:45	1.13
+++ arch/sh/kernel/signal.c	2001/01/23 07:46:38
@@ -433,7 +433,7 @@
 		current->comm, current->pid, frame, regs->pc, regs->pr);
 #endif
 
-	flush_icache_range(regs->pr, regs->pr+4);
+	flush_cache_sigtramp(regs->pr);
 	return;
 
 give_sigsegv:
@@ -507,7 +507,7 @@
 		current->comm, current->pid, frame, regs->pc, regs->pr);
 #endif
 
-	flush_icache_range(regs->pr, regs->pr+4);
+	flush_cache_sigtramp(regs->pr);
 	return;
 
 give_sigsegv:
Index: arch/sh/mm/cache.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache.c,v
retrieving revision 1.21
diff -u -r1.21 cache.c
--- arch/sh/mm/cache.c	2000/09/18 05:15:35	1.21
+++ arch/sh/mm/cache.c	2001/01/23 07:46:38
@@ -244,6 +244,22 @@
 }
 
 /*
+ * Write back the D-cache and purge the I-cache for signal trampoline. 
+ */
+void flush_cache_sigtramp(unsigned long addr)
+{
+	unsigned long v, index;
+
+	v = addr & ~(L1_CACHE_BYTES-1);
+	asm volatile("ocbwb	%0"
+		     : /* no output */
+		     : "m" (__m(v)));
+
+	index = CACHE_IC_ADDRESS_ARRAY| (v&CACHE_IC_ENTRY_MASK);
+	ctrl_outl(0, index);	/* Clear out Valid-bit */
+}
+
+/*
  * Invalidate the I-cache of the page (don't need to write back D-cache).
  *
  * Called from kernel/ptrace.c, mm/memory.c after flush_page_to_ram is called.
Index: include/asm-sh/pgtable.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgtable.h,v
retrieving revision 1.16
diff -u -r1.16 pgtable.h
--- include/asm-sh/pgtable.h	2000/11/22 07:05:18	1.16
+++ include/asm-sh/pgtable.h	2001/01/23 07:46:41
@@ -39,6 +39,7 @@
 #define flush_dcache_page(page)			do { } while (0)
 #define flush_icache_range(start, end)		do { } while (0)
 #define flush_icache_page(vma,pg)		do { } while (0)
+#define flush_cache_sigtramp(vaddr)		do { } while (0)
 #elif defined(__SH4__)
 /*
  *  Caches are broken on SH-4, so we need them.
@@ -52,6 +53,7 @@
 extern void flush_dcache_page(struct page *pg);
 extern void flush_icache_range(unsigned long start, unsigned long end);
 extern void flush_icache_page(struct vm_area_struct *vma, struct page *pg);
+extern void flush_cache_sigtramp(unsigned long addr);
 #endif
 
 /*
@@ -125,11 +127,7 @@
 /* Hardware flags: SZ=1 (4k-byte) */
 #define _PAGE_FLAGS_HARD		0x00000010
 
-#if defined(__sh3__)
-#define _PAGE_SHARED	_PAGE_HW_SHARED
-#elif defined(__SH4__)
 #define _PAGE_SHARED	_PAGE_U0_SHARED
-#endif
 
 #define _PAGE_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED | _PAGE_DIRTY)
 #define _KERNPG_TABLE	(_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY)
-- 

Re: [linuxsh-dev] Problems mounting ramdisk

[Greg B. <gb...@po...>]

Dustin McIntire wrote:
> 
> Hi. I'm working on an SH7751 based platform(Big Sur), and I'm trying to get
> the generic SH7750 kernel running. However, I'm having some trouble getting
> the kernel to find my compressed ramdisk image.  The ramdisk image is
> located in the boot flash at physical address 0x800000.  It appears that the
> ram disk block size is 1KB, so I've tried several derivatives of
> 'ramdisk_start=0x2000', but to no avial.  I get keep getting messages that
> no ram disk image can be found at whatever address I use.  What are the
> command line parameters I need to use to get the kernel to find the image?
> Part of my problem is that I don't know if virtual memory is being used at
> this point, nor do I know how the physical memory space has been mapped into
> the virtual memory space.  If anyone could be of assistance it would be
> greatly appreciated.
> Dustin.
> 

G'day Dustin,

  the "ramdisk start" parameter you poke into the empty zero
page using gdb is in units of bytes (not pages) and is an offset
from the start of RAM.  Note that the ramdisk is expected to be
in RAM when the kernel starts, not flash, so you need to copy
it there.

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] Problems mounting ramdisk

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

Hi. I'm working on an SH7751 based platform(Big Sur), and I'm trying to get
the generic SH7750 kernel running. However, I'm having some trouble getting
the kernel to find my compressed ramdisk image.  The ramdisk image is
located in the boot flash at physical address 0x800000.  It appears that the
ram disk block size is 1KB, so I've tried several derivatives of
'ramdisk_start=0x2000', but to no avial.  I get keep getting messages that
no ram disk image can be found at whatever address I use.  What are the
command line parameters I need to use to get the kernel to find the image?
Part of my problem is that I don't know if virtual memory is being used at
this point, nor do I know how the physical memory space has been mapped into
the virtual memory space.  If anyone could be of assistance it would be
greatly appreciated.
Dustin.

(gdb) cont
Continuing.
Linux version 2.4.1-pre2 (du...@du...) (gcc version 2.97
20001120 (experimental)) #4 Sun Jan 21 17:17:43 PST 2001
Warning: Unsupported machine generic, using unknown
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: mem=64M sh_mv=generic console=ttySC1,57600
ramdisk_start=0x2000
Setting GDB trap vector to 0xa0000100
CPU clock: 166.66MHz
Bus clock: 83.33MHz
Module clock: 41.66MHz
Interval = 104163
Linux version 2.4.1-pre2 (du...@du...) (gcc version 2.97
20001120 (experimental)) #4 Sun Jan 21 17:17:43 PST 2001
Warning: Unsupported machine generic, using unknown
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: mem=64M sh_mv=generic console=ttySC1,57600
ramdisk_start=0x2000
Setting GDB trap vector to 0xa0000100
CPU clock: 166.66MHz
Bus clock: 83.33MHz
Module clock: 41.66MHz
Interval = 104163
Calibrating delay loop... 166.29 BogoMIPS
Memory: 63116k/65536k available (485k kernel code, 2420k reserved, 18k data,
28k init)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
CPU: SH7750
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: Couldn't find valid RAM disk image starting at 8192.
Freeing initrd memory: 640k freed
SuperH SCI(F) driver initialized
ttySC0 at 0xffe00000 is a SCI
ttySC1 at 0xffe80000 is a SCIF

Program exited normally.
(gdb)

Re: [linuxsh-dev] Unaligned access crash in signal handlers

[Denis D. <ddo...@po...>]

I don't think this is a binutils bug. I had to apply all of Kaz Kojima's
patches at the start of this year to get shared libraries to work. I
have just rechecked the patches and I am running the latest copies of
each.

SUGIOKA Toshinobu wrote:
> 
> At 12:48 01/01/19 +1100, Denis Dowling <ddo...@po...> wrote:
> >
> >sh-2.03# xterm
> >
> >(here I type ^Z)
> >
> >[2]+  Stopped                 xterm
> >sh-2.03# bg
> >[2]+ xterm &
> >xterm: Error 50, errno 14: Bad address
> >sh-2.03#
> >[2]+  Done(50)                xterm
> >
> >
> >I am not sure if this problem is related?
> 
> I hear that xterm triggers binutils's bug.
> Kaz Kojima's latest patch may fix this problem.
> 
> Please check
> http://dodo.nurs.or.jp/~kkojima/index.html/temporary-README-new-toolchain
> 
> If you update binutils, you should rebuild gcc with new binutils
> glibc-2.2, and then all other shared libraries in this order.
> 
> Rpms of new tool chains are at http://www.sh-linux.org/rpm-index/index.html
> If you are RedHat user, please test them.

Re: [linuxsh-dev] Unaligned access crash in signal handlers

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

At 12:48 01/01/19 +1100, Denis Dowling <ddo...@po...> wrote:
>
>sh-2.03# xterm
>
>(here I type ^Z)
>
>[2]+  Stopped                 xterm
>sh-2.03# bg
>[2]+ xterm &
>xterm: Error 50, errno 14: Bad address
>sh-2.03# 
>[2]+  Done(50)                xterm
>
>
>I am not sure if this problem is related?

I hear that xterm triggers binutils's bug.
Kaz Kojima's latest patch may fix this problem.

Please check
http://dodo.nurs.or.jp/~kkojima/index.html/temporary-README-new-toolchain

If you update binutils, you should rebuild gcc with new binutils 
glibc-2.2, and then all other shared libraries in this order.

Rpms of new tool chains are at http://www.sh-linux.org/rpm-index/index.html
If you are RedHat user, please test them.


----
SUGIOKA Toshinobu

Re: [linuxsh-dev] Unaligned access crash in signal handlers

[Denis D. <ddo...@po...>]

SUGIOKA Toshinobu wrote:
> 
> At 18:45 01/01/16 +1100, Denis Dowling wrote:
> >I have been getting rare crashes in Linux 2.4.0 when handling SIGALRM
> >signals. I have managed to trace the problem down and it seems that the
> >sigreturn trap code is not getting flushed to the signal frame
> >sometimes. The problem goes away completely if I do a flush_cache_all
> >instead of flush_icache_range. I have attached a patch that does this. I
> >cannot see anything wrong with the current flush_icache_range usage but
> >suspect it is broken. The flush_cache_all is complete overkill so would
> >be very keen to hear if you have a fix for flush_icache_range.
> 
> Currently flush_icache_range uses A-bit. but A-bit works only when
> ITLB entry exists. UTLB entry should not work.
> So every I-cache entry should be compared with physical address by hand
> or all I-cache should be invalidated.

At the moment I just completely invalidate the I and U caches. Do you
have any ideas on how to do this more efficiently? I still have problems
when I try to restart processes in the background. 

sh-2.03# xterm

(here I type ^Z)

[2]+  Stopped                 xterm
sh-2.03# bg
[2]+ xterm &
xterm: Error 50, errno 14: Bad address
sh-2.03# 
[2]+  Done(50)                xterm


I am not sure if this problem is related?

Regards,
Denis.

Re: [linuxsh-dev] Unaligned access crash in signal handlers

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

At 18:45 01/01/16 +1100, Denis Dowling wrote:
>I have been getting rare crashes in Linux 2.4.0 when handling SIGALRM
>signals. I have managed to trace the problem down and it seems that the
>sigreturn trap code is not getting flushed to the signal frame
>sometimes. The problem goes away completely if I do a flush_cache_all
>instead of flush_icache_range. I have attached a patch that does this. I
>cannot see anything wrong with the current flush_icache_range usage but
>suspect it is broken. The flush_cache_all is complete overkill so would
>be very keen to hear if you have a fix for flush_icache_range.

Currently flush_icache_range uses A-bit. but A-bit works only when
ITLB entry exists. UTLB entry should not work.
So every I-cache entry should be compared with physical address by hand
or all I-cache should be invalidated.


----
SUGIOKA Toshinobu

Re: [linuxsh-dev] waitpid and 2.4.0 kernel

[Greg B. <gb...@po...>]

Denis Dowling wrote:
> 
> PS: If you have the flash space I would replace busybox sh with a real
> version of bash. It makes the target environment SO much more user
> friendly.

  Also, I found that the /etc/pcmcia scripts don't work at all
with busybox sh, they need a proper implementation of /bin/sh.

Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] waitpid and 2.4.0 kernel

[Denis D. <ddo...@po...>]

Hi Brian,

I have attached the init patch for busybox. I am still using
busybox-0.47 but I suspect this patch will work with newer versions of
busybox. This patch makes init set the SIGCHLD handling to SIG_DFL. This
should not be needed but for some reason the 2.4.0 kernel is starting
the init process with SIGCHLD set to SIG_IGN.

Regards,
Denis.

PS: If you have the flash space I would replace busybox sh with a real
version of bash. It makes the target environment SO much more user
friendly.


Bryan Rittmeyer wrote:
> 
> Denis Dowling wrote:
> 
> > The seems to be a 2.4.0 SH kernel problem but I could not find a way to fix
> > this. Instead I set SIG_CHLD to SIG_DFL in the busybox init program I am
> > using and all works correctly.
> 
> Could you please supply me a patch for this?
> 
> > I suspect that this is fixed in the latest BusyBox release and broken in
> > 0.48. Strange though?
> 
> Actually, I am still seeing this problem with 0.49pre BusyBox CVS and
> 2.4.0-pre2 LinuxSH CVS. For example:
> 
> [@(none) /]# mount -t ramfs ramfs mnt
> mount: Mounting ramfs on mnt failed: No such device
> sh: tcsetpgrp: Operation not permitted
> sh: waitpid(56): No child processes
> Process '/bin/busybox sh' (pid 11) exited.  Scheduling it for restart.
> 
> Please press Enter to activate this console.
> 
> I don't think the "tcsetpgrp" complaint is related, but I did start
> seeing it after moving up from 2.4.0-test10. Perhaps I need to upgrade
> to glibc2.2?

Re: [linuxsh-dev] waitpid and 2.4.0 kernel

[Bryan R. <br...@ix...>]

Denis Dowling wrote:

> The seems to be a 2.4.0 SH kernel problem but I could not find a way to fix
> this. Instead I set SIG_CHLD to SIG_DFL in the busybox init program I am
> using and all works correctly.

Could you please supply me a patch for this?

> I suspect that this is fixed in the latest BusyBox release and broken in
> 0.48. Strange though?

Actually, I am still seeing this problem with 0.49pre BusyBox CVS and
2.4.0-pre2 LinuxSH CVS. For example:

[@(none) /]# mount -t ramfs ramfs mnt
mount: Mounting ramfs on mnt failed: No such device
sh: tcsetpgrp: Operation not permitted
sh: waitpid(56): No child processes
Process '/bin/busybox sh' (pid 11) exited.  Scheduling it for restart.

Please press Enter to activate this console. 


I don't think the "tcsetpgrp" complaint is related, but I did start
seeing it after moving up from 2.4.0-test10. Perhaps I need to upgrade
to glibc2.2?

Bryan

-- 
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302

[linuxsh-dev] New version of CETools available !

[Ludovic L. <lud...@fr...>]

Hello,

A new version of ethload, a program to send ROM images to flash or ram 
of embedded devices, is now available for download at 
http://LinuxSH.free.fr/tools/

ethload is an unix program designed for development and prototypes CE 
boards. It allows to send on the network a file to a remote development 
board, and to save it to either Flash ROM or RAM. The board can then be 
rebooted using the new ROM (or RAM) image.

cetools is a collection of small utilities for dealing with MS BIN file 
format.

Do not hesitate to ask questions to me : mailto:li...@fr...

Best Regards,

Ludovic LANGE

[linuxsh-dev] Unaligned access crash in signal handlers

[Denis D. <ddo...@po...>]

Hello Niibe-san,

I have been getting rare crashes in Linux 2.4.0 when handling SIGALRM
signals. I have managed to trace the problem down and it seems that the
sigreturn trap code is not getting flushed to the signal frame
sometimes. The problem goes away completely if I do a flush_cache_all
instead of flush_icache_range. I have attached a patch that does this. I
cannot see anything wrong with the current flush_icache_range usage but
suspect it is broken. The flush_cache_all is complete overkill so would
be very keen to hear if you have a fix for flush_icache_range.

The problem is very difficult to reproduce in a test program. It only
happens when parts of the stack have already been mapped into the
address cache and the signal handler is very short. I have a compiled
version of lrz from the lrzsz package that consistently crashes 2.4.0
everytime it is run. I can send this to you if you want.

Regards,
Denis

Re: [linuxsh-dev] waitpid and 2.4.0 kernel

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

Hi Brian,

I put in about 2 days on this and have finally determined what is going on.
It seems the 2.4.0 kernel for the SH is starting up the init process with
SIG_CHLD set to SIG_IGN and not SIG_DFL. All child processes are getting
reaped by the init process rather than waiting around as zombies. This is
why pclose fails. 

The seems to be a 2.4.0 SH kernel problem but I could not find a way to fix
this. Instead I set SIG_CHLD to SIG_DFL in the busybox init program I am
using and all works correctly.

I suspect that this is fixed in the latest BusyBox release and broken in
0.48. Strange though?

Regards,
Denis.

----------
> From: Bryan Rittmeyer <br...@ix...>
> To: Denis Dowling <ddo...@po...>
> Cc: lin...@li...
> Subject: Re: [linuxsh-dev] waitpid and 2.4.0 kernel
> Date: Sunday, 14 January 2001 7:15
> 
> Denis Dowling wrote:
> 
> > I am trying to chace down a problem with popen() and pclose() using the
> > latest 2.4.0 kernel on the SuperH. I seems that waitpid is always
> > returning ECHILD even when the child process pid is correct and the
> > process has exited correctly. Is anyone else seeing this?
> 
> Yep. Interestingly enough, it shows up with the latest CVS version of
> BusyBox, but not with the 0.48 BusyBox release (or maybe vice versa, I
> don't remember exactly). I started noticing it after moving from -test10
> to 2.4.0, but I also changed binutils / gcc / glibc at the same time.
> Not precisely sure it's a kernel problem...
> 
> Regards,
> 
> Bryan
> 
> -- 
> Bryan Rittmeyer
> mailto:br...@ix...
> Ixia Communications
> 26601 W. Agoura Rd.
> Calabasas, CA 91302