linuxsh-dev

[linuxsh-dev] IRQ Autoprobing problem? (was Re : System reset while INIT processing)

[Masahiro A. <m-...@aa...>]

Self follow-up.

On Thu, 12 Jul 2001 09:32:47 +0900
Masahiro Abe <m-...@aa...> wrote:

> Additional info (may be related to this matter):
> Our board has SMC91C96 Ethernet controller. It worked fine with 2.4.5
> kernel. With current kernel, the driver hangs in the middle of
> initialization (in smc_findirq, at outb just after SMC_DELAY). So, I'm
> temporarily not using it now.

I think I've found the reason of this hang. In fact it is not "hang",
but "repetitive interrupt". This is not related to the other "reboot"
problem, I believe.

I'm going to explain the situation I've found out, and would like to get
your opinion which way to go.

smc9194 driver does auto-probe IRQ of the chip, and uses
probe_irq_on/off of irq.c. probe_irq_on calls startup of desc->handler
to unmask each irq with not action installed.

So far, so good. This part is not changed from 2.4.5 to current CVS.

do_IRQ in irq.c is changed between those two release.
- At the entry, desc->handler->ack is called so that irq is masked. This
is not changed.
- When no action is registered for the irq,
  * until 2.4.5, it simply returns without unmasking irq
  * from 2.4.6, it calls desc->handler->end to unmask and exit

Level interrupt is used from 9194 for our board. So, until the ack is
sent to the chip, interrupt is sent to the CPU as soon as it is unmasked.
With 2.4.5 kernel, this didn't happen because it is not unmasked. With
2.4.6 kernel, interrupt handler is called repetitively before the driver
sends ack to the chip.

What is the proper way to solve this problem? Has anybody seen this?
What did you do then? Or, my assumption is not correct?
I appreciate any input.

I can simply walk-around this by passing kernel parameter not to
auto-probe, but it's not the right way to this problem.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] [linux-sh:01802] Re: System reset while INIT processing

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

Masahiro Abe wrote:
 > No, it didn't work. It's got relatively backward, seldom see the message
 > from INIT.

Then, what you see is another bug.  In my environments (CqREEK &
SolutionEngine), it works fine now.

The email attached may be related to your issue.

------- start of forwarded message (RFC 934 encapsulation) -------
Content-Length: 1814
Message-ID: <20010711175809.F3496@athlon.random>
References: <200107110849.f6B8nlm00414@df1tlpc.local.here> <shs...@ch...> <3B4...@uo...> <151...@ch...>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <151...@ch...>; from tro...@fy... on Wed, Jul 11, 2001 at 04:22:04PM +0200
X-GnuPG-Key-URL: http://e-mind.com/~andrea/aa.gnupg.asc
X-PGP-Key-URL: http://e-mind.com/~andrea/aa.asc
Precedence: bulk
X-Mailing-List: 	lin...@vg...
From: Andrea Arcangeli <an...@su...>
Sender: lin...@vg...
To: Trond Myklebust <tro...@fy...>
Cc: Andrew Morton <an...@uo...>, Klaus Dittrich <kl...@t-...>,
   Linus Torvalds <tor...@tr...>, lin...@vg...
Subject: Re: 2.4.7p6 hang
Date: 	Wed, 11 Jul 2001 17:58:09 +0200

On Wed, Jul 11, 2001 at 04:22:04PM +0200, Trond Myklebust wrote:
> >>>>> " " == Andrew Morton <an...@uo...> writes:
> 
>      > Trond Myklebust wrote:
>     >>
>     >> ...  I have the same problem on my setup. To me, it looks like
>     >> the loop in spawn_ksoftirqd() is suffering from some sort of
>     >> atomicity problem.
> 
>      > Does a `set_current_state(TASK_RUNNING);' in spawn_ksoftirqd()
>      > fix it?  If so we have a rogue initcall...
> 
> Nope. The same thing happens as before.
> 
> A couple of debugging statements show that ksoftirqd_CPU0 gets created
> fine, and that ksoftirqd_task(0) is indeed getting set correctly
> before we loop in spawn_ksoftirqd().
> After this the second call to kernel_thread() succeeds, but
> ksoftirqd() itself never gets called before the hang occurs.

ksoftirqd is quite scheduler intensive, and while its startup is
correct (no need of any change there), it tends to trigger scheduler
bugs (one of those bugs was just fixed in pre5). The reason I never seen
the deadlock I also fixed this other scheduler bug in my tree:

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.7pre5aa1/00_sched-yield-1

this one I forgot to sumbit but here it is now for easy merging:

- --- 2.4.4aa3/kernel/sched.c.~1~	Sun Apr 29 17:37:05 2001
+++ 2.4.4aa3/kernel/sched.c	Tue May  1 16:39:42 2001
@@ -674,8 +674,10 @@
 #endif
 	spin_unlock_irq(&runqueue_lock);
 
- -	if (prev == next)
+	if (prev == next) {
+		current->policy &= ~SCHED_YIELD;
 		goto same_process;
+	}
 
 #ifdef CONFIG_SMP
  	/*


Andrea
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
------- end -------

[linuxsh-dev] Re: System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Thu, 12 Jul 2001 15:32:33 +0900 (JST)
NIIBE Yutaka <gn...@m1...> wrote:

> Masahiro Abe wrote:
>  > I've tried this, and found that it's got a little bit better. Still
>  > system reboots in INIT, but it can stand relatively longer than before.
>  > I can see output from /etc/rc.d/rc and S** sometimes (not always). I
>  > couldn't see it before this patch.
>=20
> Now, could you please try it again.  Because of jet-rag, the one I've
> committed include a bug.  I believe I've fixed.

No, it didn't work. It's got relatively backward, seldom see the message
=66rom INIT.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

Re: [linux-sh:01798] Re: [linuxsh-dev] System reset while INIT processing

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

Masahiro Abe wrote:
 > I've tried this, and found that it's got a little bit better. Still
 > system reboots in INIT, but it can stand relatively longer than before.
 > I can see output from /etc/rc.d/rc and S** sometimes (not always). I
 > couldn't see it before this patch.

Now, could you please try it again.  Because of jet-rag, the one I've
committed include a bug.  I believe I've fixed.
-- 

Re: [linux-sh:01798] Re: [linuxsh-dev] System reset while INIT processing

[Masahiro A. <m-...@aa...>]

On Thu, 12 Jul 2001 13:17:14 +0900 (JST)
NIIBE Yutaka <gn...@m1...> wrote:

> Then, I've just committed a patch to fix cache issues.  It is not the
> cache alias issue, but the cache coherency issue between I-cache and
> D-cache.  Please try it out and let me how it goes (well or worth).

Thank you Niibe-san.

I've tried this, and found that it's got a little bit better. Still
system reboots in INIT, but it can stand relatively longer than before.
I can see output from /etc/rc.d/rc and S** sometimes (not always). I
couldn't see it before this patch.

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linux-sh:01796] Re: [linuxsh-dev] System reset while INIT processing

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

David Mckay wrote:
 > Niibe-san, have you seen any problems on your system?

Not for my SolutionEngine SH7750 or SH7750S.  I've tried for my CqREEK
SH7750, I've seen the issue.

Then, I've just committed a patch to fix cache issues.  It is not the
cache alias issue, but the cache coherency issue between I-cache and
D-cache.  Please try it out and let me how it goes (well or worth).
-- 

Re[2]: [linuxsh-dev] System reset while INIT processing

[Masahiro A. <m-...@aa...>]

Thank you for your reply, David and Dustin. I'm a little bit relieved
that I'm not alone.

Additional info (may be related to this matter):
Our board has SMC91C96 Ethernet controller. It worked fine with 2.4.5
kernel. With current kernel, the driver hangs in the middle of
initialization (in smc_findirq, at outb just after SMC_DELAY). So, I'm
temporarily not using it now.

Last night I've checked out latest source from CVS (it's 2.4.7-pre6 now),
and tried it. As expected, behavior of the system is same as yesterday.
I've tried to disable CONFIG_CF_ENABLER and enable SMC91C96, but it
hangs in smc_findirq.

If I comment "outb" out in smc_findirq, it passes driver initialization.
I can see message with probed IRQ, base address, etc. This is with
CONFIG_CF_ENABLER enabled.

On Wed, 11 Jul 2001 06:55:56 -0700
"Dustin McIntire" <du...@se...> wrote:

> I'm experiencing the same problems as Masahiro-san as well, though I don't
> get reboots, just a hanging system.  I'm working on a custom SH7751 based
> platform that works fine with the 2.4.5 kernel sources.  The latest kernel
> will hang just as init starts running.
> 
> Dustin.
> 
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of David Mckay
> Sent: Wednesday, July 11, 2001 5:56 AM
> To: lin...@li...; m-...@aa...
> Subject: Re: [linuxsh-dev] System reset while INIT processing
> 
> 
> Masahiro-san,
> 	We've also found some problems with the cache handling in the latest
> kernel. Things like X-windows are no longer stable. We haven't yet had a
> chance
> to track down the source of these problems, but expect to be able to do
> soon.
> Niibe-san, have you seen any problems on your system?
> 
> I don't think it is specific to your board, I think there is a more generic
> problem here.
> 
> Cheers!

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

RE: [linuxsh-dev] System reset while INIT processing

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

I'm experiencing the same problems as Masahiro-san as well, though I don't
get reboots, just a hanging system.  I'm working on a custom SH7751 based
platform that works fine with the 2.4.5 kernel sources.  The latest kernel
will hang just as init starts running.

Dustin.

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...]On Behalf Of David Mckay
Sent: Wednesday, July 11, 2001 5:56 AM
To: lin...@li...; m-...@aa...
Subject: Re: [linuxsh-dev] System reset while INIT processing


Masahiro-san,
	We've also found some problems with the cache handling in the latest
kernel. Things like X-windows are no longer stable. We haven't yet had a
chance
to track down the source of these problems, but expect to be able to do
soon.
Niibe-san, have you seen any problems on your system?

I don't think it is specific to your board, I think there is a more generic
problem here.

Cheers!

--
Dave McKay
Software Engineer STMicroelectronics
Email: dav...@st...



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

Re: [linuxsh-dev] System reset while INIT processing

[David M. <Dav...@st...>]

Masahiro-san,
	We've also found some problems with the cache handling in the latest
kernel. Things like X-windows are no longer stable. We haven't yet had a chance
to track down the source of these problems, but expect to be able to do soon.
Niibe-san, have you seen any problems on your system?

I don't think it is specific to your board, I think there is a more generic
problem here.

Cheers!

-- 
Dave McKay 
Software Engineer STMicroelectronics
Email: dav...@st...

[linuxsh-dev] System reset while INIT processing

[Masahiro A. <m-...@aa...>]

Hello all, today I desperately need someone's help (as usual;-)

I've checked out CVS kernel last night (before Niibe-san updated it to
2.4.7-pre5/6). Today I've made modifications to it to run on our custom
board. It booted, but somehow, system is reset while INIT process.

I have applied changes to the source for irq, machvec, CompactFlash
handling only. I haven't applied ext3 and RTLinux patch yet.

System reset occurs at random location of INIT process. Sometimes I can
see several lines of output from rc.sysinit. Sometimes I can see nothing
after "Freeing unused kernel memory" message from kernel, just reset
happens.

If I make /sbin/init as link to /bin/bash, sometimes I can see bash
prompt and type some command, but sometimes system resets before that.

Our custom board has 32MB SRAM in area 2, CompactFlash in area 5.

With 2.4.5 kernel and similar modifications, our custom board can run
without problem.

I've tried same kernel on SolutionEngine 7750S. It has no problem like
this.

Can anybody suggest me something/some place to look into? I can't think
of anything how to nail down this problem now.

For reference, I've attached patch for CompactFlash handling. This is
basically the same as what I've posted before, but uses newly renamed
p3_ioremap(). This one or "irq_maskreg" patch I've posted before may be
the source of this?

Thanks in advance for your help.

---------
diff -ruN linux-2.4.6-cvs-mr/arch/sh/config.in linux-2.4.6-cvs-mr-cf/arch/sh/config.in
--- linux-2.4.6-cvs-mr/arch/sh/config.in	Wed Jul 11 09:40:56 2001
+++ linux-2.4.6-cvs-mr-cf/arch/sh/config.in	Wed Jul 11 10:45:10 2001
@@ -130,6 +130,18 @@
   bool 'Compact Flash Enabler support' CONFIG_CF_ENABLER
 fi
 
+if [ "$CONFIG_CF_ENABLER" = "y" ]; then
+ choice 'Compact Flash Area' \
+   "Area5 CONFIG_CF_AREA5 \
+    Area6 CONFIG_CF_AREA6" Area6
+ if [ "$CONFIG_CF_AREA5" = "y" ]; then
+   define_hex CONFIG_CF_BASE_ADDR b4000000
+ fi
+ if [ "$CONFIG_CF_AREA6" = "y" ]; then
+   define_hex CONFIG_CF_BASE_ADDR b8000000
+ fi
+fi
+
 bool 'Hitachi HD64461 companion chip support' CONFIG_HD64461
 if [ "$CONFIG_HD64461" = "y" ]; then
    int 'HD64461 IRQ' CONFIG_HD64461_IRQ 36
diff -ruN linux-2.4.6-cvs-mr/arch/sh/kernel/cf-enabler.c linux-2.4.6-cvs-mr-cf/arch/sh/kernel/cf-enabler.c
--- linux-2.4.6-cvs-mr/arch/sh/kernel/cf-enabler.c	Wed Jul 11 09:40:56 2001
+++ linux-2.4.6-cvs-mr-cf/arch/sh/kernel/cf-enabler.c	Wed Jul 11 14:20:41 2001
@@ -14,7 +14,8 @@
 #include <asm/io.h>
 #include <asm/irq.h>
 
-#define CF_CIS_BASE	0xb8000000
+/* this must be done in boot-loader - Masahiro Abe
+#define CF_CIS_BASE	0xb8000000 */
 /*
  * You can connect Compact Flash directly to the bus of SuperH.
  * This is the enabler for that.
@@ -29,15 +30,58 @@
  * 0xB8001000 : Common Memory
  * 0xBA000000 : I/O
  */
+#if defined(CONFIG_IDE) && defined(__SH4__)
+/* SH4 can't access PCMCIA interface through P2 area.
+ * we must remap it with appropreate attribute bit of the page set.
+ * this part is based on Greg Banks' hd64465_ss.c implementation - Masahiro Abe */
+#include <linux/mm.h>
+#include <linux/vmalloc.h>
+
+#if defined(CONFIG_CF_AREA6)
+#define slot_no 0
+#else
+#define slot_no 1
+#endif
+
+extern void * p3_ioremap(unsigned long phys_addr, unsigned long size, unsigned long flags);
+
+void *cf_io_base;
+
+static int __init allocate_cf_area(void)
+{
+	pgprot_t prot;
+	unsigned long paddrbase, psize;
+
+/* open I/O area window */
+	paddrbase = virt_to_phys((void*)CONFIG_CF_BASE_ADDR);
+	psize = PAGE_SIZE;
+	prot = PAGE_KERNEL_PCC(slot_no, _PAGE_PCC_IO16);
+	cf_io_base = p3_ioremap(paddrbase, psize, prot.pgprot);
+	if (!cf_io_base) {
+		printk("allocate_cf_area : can't open CF I/O window!\n");
+		return -ENOMEM;
+	}
+/*	printk("p3_ioremap(paddr=0x%08lx, psize=0x%08lx, prot=0x%08lx)=0x%08lx\n",
+	    	paddrbase, psize, prot.pgprot, cf_io_base);*/
+
+	/* XXX : do we need attribute and common-memory area also? */
+
+	return 0;
+}
+#endif
 
 static int __init cf_init_default(void)
 {
 #ifdef CONFIG_IDE
+#if defined(CONFIG_IDE) && defined(__SH4__)
+	allocate_cf_area();
+#endif
 	/* Enable the card, and set the level interrupt */
-	ctrl_outw(0x0042, CF_CIS_BASE+0x0200);
+/* this must be done in boot-loader - Masahiro Abe
+	ctrl_outw(0x0042, CF_CIS_BASE+0x0200);*/
 #endif
-	make_imask_irq(14);
-	disable_irq(14);
+/*	make_imask_irq(14);
+	disable_irq(14);*/
 	return 0;
 }
 
----------

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] (Very) small fix to machvec.h

[Masahiro A. <m-...@aa...>]

I think I've found very small mistake in include/asm-sh/machvec.h, in
both official 2.4.6 and current CVS.

Position of "#endif" may be wrong. Here is the patch.

---------------------------
--- machvec.h	Wed Jul 11 14:33:55 2001
+++ machvec.h.fix	Wed Jul 11 14:34:46 2001
@@ -119,7 +119,6 @@
 # else
 #  define MACH_HP690		0
 # endif
-# endif
 # ifdef CONFIG_HD64461
 #  define MACH_HD64461		1
 # else
@@ -149,6 +148,7 @@
 #  define MACH_BIGSUR		1
 # else
 #  define MACH_BIGSUR		0
+# endif
 #endif
 
 #endif /* _ASM_SH_MACHVEC_H */
---------------------------

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Split cache code for SH3 and SH4.

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

David Woodhouse wrote:
 > #ifdefs confuse me. As there's almost nothing common between the SH3 and SH4
 > code in cache.c, it looks like it makes sense to split them into separate
 > files.

That's good idea.  Thanks for the patch.  I'll integrate yours.

However, for a while, to get the feedback of the recent changes, I
don't apply it immediately.  Please be patient.
-- 

[linuxsh-dev] Re: [linux-sh:01769] Re: SH4 hardware problem

[Gareth S. L. <ga...@el...>]

In message <200...@we...>
          Barkuson <bar...@ya...> wrote:

> Thanks, Doug.
> 
> /RDY was pulled up by an FPGA pin. After adding a
> pulled down resister, the cpu now reads from the Flash
> and executing the sh-ipl now (well not quite, still
> need to set up the SDRAM). Thanks again.

A little tip that I found useful - if you modify the CCR initialisation to
use part of the cache as memory mapped RAM, you can use this area for the
IPL's stack and variable storage - then you can use the debugger to test the
presence of the SDRAM in area 2 or 3 without having to reflash all the time.

-- 
Gatch

Re: [linuxsh-dev] Build difficulties

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

James Harris wrote:

> I would have thought that the CVS checkout would be the latest? (from
> sourceforge) is this correct?

You did [presumably] get the latest tools from SourceForge, but those
tools
are not the latest available... you might want to look at
www.m17n.org/linux-sh
for info, and/or www.linux-sh.org (where all kinds of source and binary
packages
are available too).

--Jeremy

[linuxsh-dev] Build difficulties

[James H. <har...@se...>]

Greetings all,

I am continuing to have difficulties building the kernel for the SH3
solution engine.

I did a CVS check out with:

... co binutils
... co kernel
... co gcc-core

The binutils and gcc-core built and installed without problem. However
the kernel build still gives errors relating to apostrophes in the
entry.S file and DECLARE_MUTEX in irq.c
The last time I had these problems I was advised that I needed newer
tools:
I would have thought that the CVS checkout would be the latest? (from
sourceforge) is this correct?

I feel so close yet so far from having the kernel going!

Any help will be greatly appreciated.


Cheers,

James

[linuxsh-dev] Re: [linux-sh:01774] Re: Jornada

[Joseph A. K. <jk...@ea...>]

"Mark W. Alexander" wrote:
> 
> 
> My biggest success was this morning with shlo, an empty initrd and a
> kernel for the hp690. It flashed repeatedly and would not stop until I
> managed to hit the hard reset combination at just the right time. The
> good(?) news is that somthing did hit the serial port, writing
> gibberish to my minicom session and disabling all keyboard and mouse
> I/O to the desktop machine until I performed a cold boot. Telnetting
> in and doing a warm reboot still did not reset the keyboard and
> mouse. Something definitely came out of the serial port. (I think was
> "Gozer the Destructor".)
> 
> Yes, at the stage I'm at, I'm calling this success. Ok, maybe just
> "progress". But I think it's saying if I knew what _really_ goes in
> shlo.txt I could probably get a serial console session going.

Serial output! You lucky dog. The best I was ever able to do
was to get my 430se to soft-reset. That was with shlo and
a kernel I'd hacked to use the "generic" inb/outb functions.
I built an uncompressed kernel and pointed the start symbol
in shlo.txt at the beginning of the .text segment, but I'm
not at all sure that was the right thing to do.

-- Joe Knapka
"You know how many remote castles there are along the gorges? You
 can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. *

[linuxsh-dev] Re: [linux-sh:01773] Re: Jornada

[Mark W. A. <sl...@do...>]

On Sun, 8 Jul 2001, Brian K. White wrote:
> gahh this sucks!
> 
> I'm going on a trip which is at least 1/2 recreation, where a good portion
> of the other people I'll be hanging out with will be out-geeking each other
> and I've already stuck a "Linux Inside" sticker on my Jornada, which would
> have secured my title this trip. :)
> 
> now I'd better peel it off. Hmm, or I could just stick the kernel and root
> fs on there... so what if it doesn't load...
> 
> I could not figure out how to even try out the 320x240 kernel with ldd
> I can't find any text anywhere
> my best guess is I think I remember seeing about one sentence somewhere that
> suggested you create an ext2 filesystem on and popuplate a cf card with the
> usual stuff, including a kernel and some programs, by using a cf card
> adapter on a regular linux box. For me, I'm guessing that means I sould get
> a cf<->pcmcia adapter for my laptop, which has mandrake 8.0 and kernel 2.4.5
> on one partition and the Win2Kpro with the WinCE ActiveSync utility on
> another partition.

You should be able to build an initrd that boots a simple system up on
a ramdisk. Booting would require a bootloader (I've been investigating
lld, shlo, hpcboot, pdsboot, and redboot NONE of which claim 548
support, sigh), a kernel image and an initrd image.  These could live
on a CE formated CF card in the same way that LOADLIN can boot a
kernel and initrd from a Windows filesystem.  Once you get that far,
you could do everything else via the Jornada itself.

So far, I've tried lld and shlo, with various binary kernels
downloaded from shlinux sites. I pretty much don't expect anything on
the screen from these, but was hoping to see a little action on the
serial port.

My biggest success was this morning with shlo, an empty initrd and a
kernel for the hp690. It flashed repeatedly and would not stop until I
managed to hit the hard reset combination at just the right time. The
good(?) news is that somthing did hit the serial port, writing
gibberish to my minicom session and disabling all keyboard and mouse
I/O to the desktop machine until I performed a cold boot. Telnetting
in and doing a warm reboot still did not reset the keyboard and
mouse. Something definitely came out of the serial port. (I think was
"Gozer the Destructor".)

Yes, at the stage I'm at, I'm calling this success. Ok, maybe just
"progress". But I think it's saying if I knew what _really_ goes in
shlo.txt I could probably get a serial console session going.

> too bad... this thing looks like it could really wipe the floor with the
> Agenda.
> I hope someone works it out before the thing becomes *too* obsolete. It's
> already lost a lot of it's shine to the compaq's and casiopea's that have
> similar ram and cpu specs, but with better screens (reflective screens that
> work outdoors and other bright light)

That's what's so frustrating. Seeing other machines, even SH3 based,
actually running linux.

> I can't help get the initial core work of getting a kernel to run and mount
> a fylesystem and control the hardware, but I'd be more than ready, willing,
> and able to compile apps and maintain a distribution and write up a "how-to
> run linux on your Jornada"

I can handle building a kernel and initrd. I don't anticipate getting
XFree ported will be as difficult as getting the hardware specs
required to do it. What I need is someone who can get me to that first
boot with a serial console. Trial and error is painful, and tedious
(but it's a technique I understand;)

> It looks like that debian page goes a long way towards this already.

What debian page? Is it the 548, or Jornada's.

Mark

[linuxsh-dev] Re: [linux-sh:01771] Re: Jornada

[Brian K. W. <br...@al...>]

----- Original Message -----
From: "Mark W. Alexander" <sl...@do...>
To: "Joseph A. Knapka" <jk...@ea...>
Cc: "Brian K. White" <br...@al...>; <lin...@m1...>;
<lin...@li...>
Sent: Saturday, July 07, 2001 3:51 PM
Subject: [linux-sh:01771] Re: Jornada


> On Fri, 6 Jul 2001, Joseph A. Knapka wrote:
>
> >
> > Wow, really? I contacted HP about my Jornada 430 about nine months
> > ago and they basically said, "Fuggeddaboudit." If Mr. Perens can get
> > us hardware documentation for these beasties, progress can be made!
> >
> > Incidentally, re. the display issue, the display controller on
> > the J430 is off the shelf, and data about it is available.
> > The sticky part with the 430 is that there's at least one proprietary
> > HP chip for which I have not found any documentation. It's
> > labelled "112585 9904KU203". Not sure if the 5xx series are
> > similar.
>
> I specifically asked him if I could call on him for hardware
> questions. He's obviously _not_ the person to answer, but he _could_ be
> the person to find the person to answer. I'll confess here and now
> that, so far, I'm too ignorant to ask an intelligent question about
> these little beasties. I'm still trying to figure out how they fit a
> whole computer into a single room;)
>
> If someone can re-phrase "What the heck is IN the 548, anyway?" into a
> set of sensible questions, I'd be happy to forward them on and see
> what comes back.
>
> Mark
>
>

gahh this sucks!

I'm going on a trip which is at least 1/2 recreation, where a good portion
of the other people I'll be hanging out with will be out-geeking each other
and I've already stuck a "Linux Inside" sticker on my Jornada, which would
have secured my title this trip. :)

now I'd better peel it off. Hmm, or I could just stick the kernel and root
fs on there... so what if it doesn't load...

I could not figure out how to even try out the 320x240 kernel with ldd
I can't find any text anywhere
my best guess is I think I remember seeing about one sentence somewhere that
suggested you create an ext2 filesystem on and popuplate a cf card with the
usual stuff, including a kernel and some programs, by using a cf card
adapter on a regular linux box. For me, I'm guessing that means I sould get
a cf<->pcmcia adapter for my laptop, which has mandrake 8.0 and kernel 2.4.5
on one partition and the Win2Kpro with the WinCE ActiveSync utility on
another partition.

too bad... this thing looks like it could really wipe the floor with the
Agenda.
I hope someone works it out before the thing becomes *too* obsolete. It's
already lost a lot of it's shine to the compaq's and casiopea's that have
similar ram and cpu specs, but with better screens (reflective screens that
work outdoors and other bright light)

I can't help get the initial core work of getting a kernel to run and mount
a fylesystem and control the hardware, but I'd be more than ready, willing,
and able to compile apps and maintain a distribution and write up a "how-to
run linux on your Jornada"

It looks like that debian page goes a long way towards this already.

Brian K. White  --  br...@al...  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani

[linuxsh-dev] Re: [linux-sh:01767] Re: Jornada

[Mark W. A. <sl...@do...>]

On Fri, 6 Jul 2001, Joseph A. Knapka wrote:

> 
> Wow, really? I contacted HP about my Jornada 430 about nine months
> ago and they basically said, "Fuggeddaboudit." If Mr. Perens can get
> us hardware documentation for these beasties, progress can be made!
> 
> Incidentally, re. the display issue, the display controller on
> the J430 is off the shelf, and data about it is available.
> The sticky part with the 430 is that there's at least one proprietary
> HP chip for which I have not found any documentation. It's
> labelled "112585 9904KU203". Not sure if the 5xx series are
> similar.

I specifically asked him if I could call on him for hardware
questions. He's obviously _not_ the person to answer, but he _could_ be
the person to find the person to answer. I'll confess here and now
that, so far, I'm too ignorant to ask an intelligent question about
these little beasties. I'm still trying to figure out how they fit a
whole computer into a single room;)

If someone can re-phrase "What the heck is IN the 548, anyway?" into a
set of sensible questions, I'd be happy to forward them on and see
what comes back.

Mark

[linuxsh-dev] Re: [linux-sh:01760] SH4 hardware problem

[<bar...@ya...>]

Thanks, Doug.

/RDY was pulled up by an FPGA pin. After adding a
pulled down resister, the cpu now reads from the Flash
and executing the sh-ipl now (well not quite, still
need to set up the SDRAM). Thanks again.

Mark


 --- Doug Martens <mar...@sy...> wrote: >
Barkuson,
> 
> The /RDY line should be idled low and actively
> driven high when the user wishes to add extra wait
> states beyond what is required through the bus state
> controller(BSC).  The BSC acts differently then
> expected.  First it waits the required number of
> cycles programmed within the BSC in WCR2(wait
> control register 2) then it samples /RDY waiting for
> that line to be asserted.  After that line is
> asserted it will end that cycle successfully.  The
> default mode, which is what you will observe at
> reset time, is 15 cycles inserted and then wait for
> /RDY assertion.
> 
> Change your hardware to idle /RDY low during at
> least CS0 accesses.  Hopefully this helps.
> 
> Doug Martens
> Senior Design Engineer
> mar...@sy...
> 1000 Waverley St.
> Winnipeg, MB, Canada
> R3T 0P3
> Symbol Technologies, Winnipeg
> Ph: (204) 478-8046
> www.symbol.com
> 
> 
> >>> Barkuson <bar...@ya...> 07/04/01 12:58PM
> >>>
> Hi Doug:
> 
> Thanks for your help, you are a life saver.
> I went through the following pins and tried
> different
> settings. Unfortunately, the address line still does
> not advance from reset address 0x00000000.
> 
> >First a couple of questions;
> >    1. What is the state of /RDY?
> This pin is pulled high, and sits on high.
> 
> >    2. What is the state of /MRESET?
> This pin is also pulled high and sits on high.
> 
> >    3. What is the state of /TRST?
> This pin is pulled low. If this pin is pulled high,
> the CPU stays in reset status.
> 
> >    4. During power up reset and operation what was
> >the mode pin settings, and was the correct timing
> >observed?
> The mod pins are as followed:
> MOD0 high
> MOD1 low
> MOD2 high   (for 6:3:3/2 clock setting)
> 
> MOD3 high
> MOD4 low    (8 bit for Area 0 - 8 bit Flash memory)
> 
> MOD5 high   little endian
> MOD6 high   normal memory
> MOD7 high   master
> MOD8 high   crystal resonator
> 
> Orignally, the 1.95 is brought up around 200ms after
> 3.3V, the reset line becomes high at the same time
> as
> the 1.95V.
> The reset circuit was modified, now, the reset line
> comes up 150ms after 1.95V is up. 
> 
> >    5. What type of memory and in what
> configuration
> >is the memory configured?
> Area 0 1MB FLASH memory 10MHz (8bit data bus)
> Area 3 8MB SDRAM 100MHz  (32bit data bus)
> Area 4 512kB SRAM 100MHz (32bit data bus)
> 
> >Getting the board to read the reset vector is the
> >first hurdle.  The second hurdle with the SH4 is
> the
> >proper start timing configuration for DRAM/SDRAM!
> 
> Is there anything else I should look out for??? I
> suppose that this can only be a hardware problem
> (pin
> settings). Since that bus should read at least 2
> 8-bit
> data from the Flash memory before the first
> instruction is fetched for execution. Is this true??
> 
> Thanks again, 
> 
> Mark
> 
> 
> 
> --- Doug Martens <mar...@sy...> wrote: >
> First
> a couple of questions;
> >     1. What is the state of /RDY?
> >     2. What is the state of /MRESET?
> >     3. What is the state of /TRST?
> >     4. During power up reset and operation what
> was
> > the mode pin settings, and was the correct timing
> > observed?
> >     5. What type of memory and in what
> configuration
> > is the memory configured?
> > 
> > Getting the board to read the reset vector is the
> > first hurdle.  The second hurdle with the SH4 is
> the
> > proper start timing configuration for DRAM/SDRAM!
> > 
> > Doug Martens
> > Senior Design Engineer
> > mar...@sy...
> > 1000 Waverley St.
> > Winnipeg, MB, Canada
> > R3T 0P3
> > Symbol Technologies, Winnipeg
> > Ph: (204) 478-8046
> > www.symbol.com
> > 
> > 
> > >>> Barkuson <bar...@ya...> 07/04/01 08:42AM
> > >>>
> > 
> > Hi,
> > 
> > Firstly, my apologies for sending this mail if
> this
> > is
> > not relevent to the mailing list. However, this is
> > quite urgent, sorry. Could any hardware people
> help
> > me
> > out please?
> > 
> > I have a custom Sh4 (SH7750) board which has not
> > been
> > able to run :(. Everything looks alright except
> that
> > the board boots up and sits at address 0x00000000
> > (the
> > data at this address in the flash memory is on the
> > data bus). The CPU seems to halt at this point
> with
> > the following board status,
> > 
> > - both main crystal and rtc crystal running
> > - both status pin at low level
> > - all NMI and IRL pins pulled up
> > - BREQ pulled up
> > - address sits at 0x00000000 and does not
> increments
> > - CS0 low 
> > - RD low
> > - all WE high
> > 
> > Is there anything else that I should check?? or
> any
> > setting that I could be missing??
> > 
> > Can anyone direct me to a right place??
> > 
> > All helps are greatly appreciated. 
> > 
> > Mark
> > 
> > 
> >
>
_____________________________________________________________________________
> > http://messenger.yahoo.com.au - Yahoo! Messenger
> > - Voice chat, mail alerts, stock quotes and
> > favourite news and lots more!
> >  
> 
>
_____________________________________________________________________________
> http://messenger.yahoo.com.au - Yahoo! Messenger
> - Voice chat, mail alerts, stock quotes and
> favourite news and lots more!
>  

_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

[linuxsh-dev] Re: [linux-sh:01767] Re: Jornada

[Joseph A. K. <jk...@ea...>]

"Mark W. Alexander" wrote:
> 
> On Sun, 1 Jul 2001, Brian K. White wrote:
> 
> > Hi,
> >
> > What is the state of the art of linux-sh on the HP Jornada? specifically the
> > 540 series, more specifically, the 548, more more specifically, assume
> > plenty of room via a 256 meg CF card.
> 
> Since no one more knowledgable has responded, I can pipe up to let you
> know that I have found exactly nothing specific to the 548. (Unless
> you count people asking if there's anything available;)
> 
> > If I assume that the precompiled kernel for 240x320 devices and boot loader
> > work, that leaves the question of, does anyone have distribution cabbled
> > together? perhaps something like tomsrtbt, where everything is tiny and most
> > utilities are just tiny awk scripts, nc scripts, and busybox?
> 
> I haven't had any luck there either. I've tried a couple versions of
> lld, and a couple 240x320 kernels. The most recent of which came from
> the sourceforge linxce project:
> http://sourceforge.net/projects/linuxce/
> 
> The best I've been able to accomplish is soft-reset my 548.  Any help
> on getting a bootloader functioning would be appreciated. The minixsh
> project has apparently had some success with a 690. I was thinking of
> heading that direction long enough to get an understanding of how
> these teeny things boot (http://minixsh.tripod.co.jp/DL11_E.html).
> That's assuming that it's a relatively simple process. I find the
> sh+ipl+gdb docs intimidating, but have pretty much resigned myself to
> it. I just don't have the time right now.
> 
> > Now the really ludicrous question... what is the possibility of the video
> > ever being supported by Xfree86? (secretly hoping the video is the same or
> > similar to the yopy or the agenda...)
> 
> Better now that Bruce Perens is at HP. I contacted him when I first
> got mine and he pointed me here. He also said that he would help press
> HP for information if I needed it.

Wow, really? I contacted HP about my Jornada 430 about nine months
ago and they basically said, "Fuggeddaboudit." If Mr. Perens can get
us hardware documentation for these beasties, progress can be made!

Incidentally, re. the display issue, the display controller on
the J430 is off the shelf, and data about it is available.
The sticky part with the 430 is that there's at least one proprietary
HP chip for which I have not found any documentation. It's
labelled "112585 9904KU203". Not sure if the 5xx series are
similar.

-- Joe Knapka
"You know how many remote castles there are along the gorges? You
 can't MOVE for remote castles!" -- Lu Tze re. Uberwald
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. *

[linuxsh-dev] Re: [linux-sh:01751] Jornada

[Mark W. A. <sl...@do...>]

On Sun, 1 Jul 2001, Brian K. White wrote:

> Hi,
> 
> What is the state of the art of linux-sh on the HP Jornada? specifically the
> 540 series, more specifically, the 548, more more specifically, assume
> plenty of room via a 256 meg CF card.

Since no one more knowledgable has responded, I can pipe up to let you
know that I have found exactly nothing specific to the 548. (Unless
you count people asking if there's anything available;)

> If I assume that the precompiled kernel for 240x320 devices and boot loader
> work, that leaves the question of, does anyone have distribution cabbled
> together? perhaps something like tomsrtbt, where everything is tiny and most
> utilities are just tiny awk scripts, nc scripts, and busybox?

I haven't had any luck there either. I've tried a couple versions of
lld, and a couple 240x320 kernels. The most recent of which came from 
the sourceforge linxce project:
http://sourceforge.net/projects/linuxce/

The best I've been able to accomplish is soft-reset my 548.  Any help
on getting a bootloader functioning would be appreciated. The minixsh
project has apparently had some success with a 690. I was thinking of
heading that direction long enough to get an understanding of how
these teeny things boot (http://minixsh.tripod.co.jp/DL11_E.html).
That's assuming that it's a relatively simple process. I find the
sh+ipl+gdb docs intimidating, but have pretty much resigned myself to
it. I just don't have the time right now.

> Now the really ludicrous question... what is the possibility of the video
> ever being supported by Xfree86? (secretly hoping the video is the same or
> similar to the yopy or the agenda...)

Better now that Bruce Perens is at HP. I contacted him when I first
got mine and he pointed me here. He also said that he would help press
HP for information if I needed it.


-- 
Mark W. Alexander
sl...@do...

[linuxsh-dev] Re[2]: Strange behavior when accessing mmap'd framebuffer

[Masahiro A. <m-...@aa...>]

Hi David, I really, really thank you so much. It seems to work fine now
with what you suggested! RTLinux task wake-up time is now below 70
microseconds. I'm very happy with this.

I also would like to take a look at latest round of patches, but I must
provide workable kernel to another developer soon, so for now I'll go
with this hack. I sure will try new code soon.

Thanks again, it really helped us a lot!

On Wed, 4 Jul 2001 18:09:21 +0100
David Mckay <Dav...@st...> wrote:

> On Jul 4, 10:10pm, m-...@aa... wrote:
> > Subject: [linuxsh-dev] Strange behavior when accessing mmap'd framebuffer
> >
> > Hello all,
> >
> > Today I would like to get comments/suggestions on my problem, if you
> > have. I'll really appreciate any info you would provide.
> >
> > I'm running custom SH4 machine with LCD controller (Epson s1d13706) with
> > monochrome LCD, using it as framebuffer device. It can be accessed as
> > /dev/fb0 now.
> > When I access mmap'd framebuffer memory area from user program (by
> > memcpy, for example), sometimes it takes very long time to complete.
> > Writing (unsigned char)0x00 to the area sometimes took more than 700
> > microseconds. Usually it takes just about 10 microseconds.
> >
> 
> We have seen exactly this behaviour. It is caused by the TLB handler code
> (Pre the latest patches). What happens is the dcache aliasing code kicks in,
> causing all TLB entries to be scanned.
> 
> As a quick hack, what I did was change the code in update_mmu_cache() to
> instead of
> 
> if(pte_shared(pte))
> 
> to if(pte_shared(pte) && pte_cacheable(pte))
> 
> Dcache aliasing can't happen if the memory is uncached.
> 
> Anyway, this provided a big performance increase for me.
> 
> We actually were going to rewrite the whole of the way the dcache aliasing was
> done, but as usual Niibe beat us to it:-) That's another bug chunk of work gone
> from our project plan!
> 
> The latest kernel should fix this problem I think, but I haven't tested it yet,
> for framebuffer access, although it appears stable to me for other purposes.
> 
> Hope this helps!

+-------------------------------------+
| Masahiro Abe, Software Engineer     |
| A&D Co., Ltd. of Tokyo, Japan       |
| mailto:m-...@aa...            |
+-------------------------------------+
|This is my opinion, not my employer's|
+-------------------------------------+

[linuxsh-dev] Re: [linux-sh:01760] SH4 hardware problem

[Doug M. <mar...@sy...>]

Barkuson,

The /RDY line should be idled low and actively driven high when the user =
wishes to add extra wait states beyond what is required through the bus =
state controller(BSC).  The BSC acts differently then expected.  First it =
waits the required number of cycles programmed within the BSC in WCR2(wait =
control register 2) then it samples /RDY waiting for that line to be =
asserted.  After that line is asserted it will end that cycle successfully.=
  The default mode, which is what you will observe at reset time, is 15 =
cycles inserted and then wait for /RDY assertion.

Change your hardware to idle /RDY low during at least CS0 accesses.  =
Hopefully this helps.

Doug Martens
Senior Design Engineer
mar...@sy...
1000 Waverley St.
Winnipeg, MB, Canada
R3T 0P3
Symbol Technologies, Winnipeg
Ph: (204) 478-8046
www.symbol.com


>>> Barkuson <bar...@ya...> 07/04/01 12:58PM >>>
Hi Doug:

Thanks for your help, you are a life saver.
I went through the following pins and tried different
settings. Unfortunately, the address line still does
not advance from reset address 0x00000000.

>First a couple of questions;
>    1. What is the state of /RDY?
This pin is pulled high, and sits on high.

>    2. What is the state of /MRESET?
This pin is also pulled high and sits on high.

>    3. What is the state of /TRST?
This pin is pulled low. If this pin is pulled high,
the CPU stays in reset status.

>    4. During power up reset and operation what was
>the mode pin settings, and was the correct timing
>observed?
The mod pins are as followed:
MOD0 high
MOD1 low
MOD2 high   (for 6:3:3/2 clock setting)

MOD3 high
MOD4 low    (8 bit for Area 0 - 8 bit Flash memory)

MOD5 high   little endian
MOD6 high   normal memory
MOD7 high   master
MOD8 high   crystal resonator

Orignally, the 1.95 is brought up around 200ms after
3.3V, the reset line becomes high at the same time as
the 1.95V.
The reset circuit was modified, now, the reset line
comes up 150ms after 1.95V is up.=20

>    5. What type of memory and in what configuration
>is the memory configured?
Area 0 1MB FLASH memory 10MHz (8bit data bus)
Area 3 8MB SDRAM 100MHz  (32bit data bus)
Area 4 512kB SRAM 100MHz (32bit data bus)

>Getting the board to read the reset vector is the
>first hurdle.  The second hurdle with the SH4 is the
>proper start timing configuration for DRAM/SDRAM!

Is there anything else I should look out for??? I
suppose that this can only be a hardware problem (pin
settings). Since that bus should read at least 2 8-bit
data from the Flash memory before the first
instruction is fetched for execution. Is this true??

Thanks again,=20

Mark



--- Doug Martens <mar...@sy...> wrote: > First
a couple of questions;
>     1. What is the state of /RDY?
>     2. What is the state of /MRESET?
>     3. What is the state of /TRST?
>     4. During power up reset and operation what was
> the mode pin settings, and was the correct timing
> observed?
>     5. What type of memory and in what configuration
> is the memory configured?
>=20
> Getting the board to read the reset vector is the
> first hurdle.  The second hurdle with the SH4 is the
> proper start timing configuration for DRAM/SDRAM!
>=20
> Doug Martens
> Senior Design Engineer
> mar...@sy...
> 1000 Waverley St.
> Winnipeg, MB, Canada
> R3T 0P3
> Symbol Technologies, Winnipeg
> Ph: (204) 478-8046
> www.symbol.com
>=20
>=20
> >>> Barkuson <bar...@ya...> 07/04/01 08:42AM
> >>>
>=20
> Hi,
>=20
> Firstly, my apologies for sending this mail if this
> is
> not relevent to the mailing list. However, this is
> quite urgent, sorry. Could any hardware people help
> me
> out please?
>=20
> I have a custom Sh4 (SH7750) board which has not
> been
> able to run :(. Everything looks alright except that
> the board boots up and sits at address 0x00000000
> (the
> data at this address in the flash memory is on the
> data bus). The CPU seems to halt at this point with
> the following board status,
>=20
> - both main crystal and rtc crystal running
> - both status pin at low level
> - all NMI and IRL pins pulled up
> - BREQ pulled up
> - address sits at 0x00000000 and does not increments
> - CS0 low=20
> - RD low
> - all WE high
>=20
> Is there anything else that I should check?? or any
> setting that I could be missing??
>=20
> Can anyone direct me to a right place??
>=20
> All helps are greatly appreciated.=20
>=20
> Mark
>=20
>=20
>
___________________________________________________________________________=
__
> http://messenger.yahoo.com.au - Yahoo! Messenger
> - Voice chat, mail alerts, stock quotes and
> favourite news and lots more!
> =20

___________________________________________________________________________=
__
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!

Re: [linux-sh:01761] RE: [linuxsh-dev] SH4 hardware problem

[<bar...@ya...>]

Hi Dustin:

Thank you for help

The RDY pin is high and being pulled high by a
resistor. The CPU does seem like it is waiting for
something?? Since the chip sits on the first byte (I
have 8bit Flash memory for area 0), this means that
the CPU has not yet read the first instruction.
Therefore, the cpu basically sits on the resetted
state.

Mark

 --- Dustin McIntire <du...@se...> wrote: > Hi
Mark,
> I don't know about the SH7750, but the SH7751 has a
> RDY# pin that forces the
> processor to stall indefinately waiting for the bus
> cycle to complete.  You
> may want to check this and make sure it is not
> asserted (ie make sure it is
> logic high).  There should be and external pullup
> resistor on this pin as
> well.
> 
> Dustin.
> 
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On
> Behalf Of Barkuson
> Sent: Wednesday, July 04, 2001 6:43 AM
> To: lin...@m1...;
> lin...@li...
> Subject: [linuxsh-dev] SH4 hardware problem
> 
> 
> 
> Hi,
> 
> Firstly, my apologies for sending this mail if this
> is
> not relevent to the mailing list. However, this is
> quite urgent, sorry. Could any hardware people help
> me
> out please?
> 
> I have a custom Sh4 (SH7750) board which has not
> been
> able to run :(. Everything looks alright except that
> the board boots up and sits at address 0x00000000
> (the
> data at this address in the flash memory is on the
> data bus). The CPU seems to halt at this point with
> the following board status,
> 
> - both main crystal and rtc crystal running
> - both status pin at low level
> - all NMI and IRL pins pulled up
> - BREQ pulled up
> - address sits at 0x00000000 and does not increments
> - CS0 low
> - RD low
> - all WE high
> 
> Is there anything else that I should check?? or any
> setting that I could be missing??
> 
> Can anyone direct me to a right place??
> 
> All helps are greatly appreciated.
> 
> Mark
> 
> 
>
____________________________________________________________________________
> _
> http://messenger.yahoo.com.au - Yahoo! Messenger
> - Voice chat, mail alerts, stock quotes and
> favourite news and lots more!
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
>
http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>  

_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!