linuxsh-dev

Re: [linuxsh-dev] Some IDE drives have problems with the SolutionEngine

[Rene M. <re...@li...>]

Adrian Stoica wrote:


Does anyone know where one can get hold on one of those SolotionEngine
cards?

/Rene

[linuxsh-dev] Some IDE drives have problems with the SolutionEngine

[Adrian S. <adr...@po...>]

Hi,

It seems that not all drives are equally happy with the SolutionEngine;
after wasting nearly a week trying to get a Western Digital WDAC33100 to
work on my system, I gave up and replaced it with a Seagate drive, which so
far has not displayed any problems.
More specifically, the issue with the WD drive was that right on start-up it
was getting into the BUSY state and would never assert DataRequest, no
matter how long you polled waiting for it. Specifying ide0=reset on the
kernel command line didn't help; it would only stop if I sent it
WIN_IDLEIMMEDIATE, but then it would enter a vegetative state and further
attempts to get DataRequest asserted would result in errors.
Interestingly enough, the drive would become available after an interrupt
occurred e.g. a hard-coded breakpoint.
The drive works fine on a PC, so I suspect that it's something to do with
the combination SMSC controller + drive? I had a look at SMSC initialization
code in the gdb stub (which I use to boot) and found nothing wrong.
Any ideas?


Adrian

Re: [linuxsh-dev] RPMs

[Jaswinder S. <jas...@ya...>]

Dear Mitch :-)

Thank you very much for your help . 

I add -lpthread to compile line and everything becomes
fine :-)

Thanks .

Best Regards ,

Jaswinder.


--- Mitch Davis <md...@po...> wrote:
> Jaswinder Singh wrote:
> > 
> > Dear Stuart , Stephen and linuxsh-dev group,
> > 
> > I compiled simple C++ Hello world program as :-
> > 
> > sh-linux-gnu-g++ -ml -m3 hello.cpp
> > 
> > but i get :-
> > 
> >
>
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
> > o): In function `istream::get(char &)':
> >
>
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:91:
> >  undefined reference to
> `_pthread_cleanup_push_defer'
> >
>
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:91:
> >  undefined reference to
> `_pthread_cleanup_pop_restore'
> 
> Hi Jaswinder,
> 
> I'm not an expert in such things, but it appears
> that all the
> unresolved symbols are of the form, "_pthread_*". 
> So it looks to me as
> if
> your program uses pthreads, but is not specifying
> that the program
> should
> be linked against the pthread library.
> 
> Just as a guess, try adding -lpthread to your
> compile line.
> 
> > Do You Yahoo!?
> > 
> > From homework help to love advice, Yahoo! Experts
> has your answer.
> > http://experts.yahoo.com/
> 
> You may be interested to know that this Yahoo
> advertisement contravenes
> RFC822, the standard for mail message exchange,
> because it starts the
> line with "From ".  Starting a line with "From "
> indicates the start
> of a new message.  If a message contains a From at
> the start of the
> line, it should be escaped with ">", ie, ">From ".  
> 
> While I know there's nothing you can do about it,
> failure to quote
> the "From " causes problems with many mail readers,
> such as Netscape,
> which is what I use.
> 
> Regards,
> 
> Mitch.


__________________________________________________
Do You Yahoo!?
From homework help to love advice, Yahoo! Experts has your answer.
http://experts.yahoo.com/

Re: [linuxsh-dev] RPMs

[Mitch D. <md...@po...>]

Jaswinder Singh wrote:
> 
> Dear Stuart , Stephen and linuxsh-dev group,
> 
> I compiled simple C++ Hello world program as :-
> 
> sh-linux-gnu-g++ -ml -m3 hello.cpp
> 
> but i get :-
> 
> /opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
> o): In function `istream::get(char &)':
> /home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:91:
>  undefined reference to `_pthread_cleanup_push_defer'
> /home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:91:
>  undefined reference to `_pthread_cleanup_pop_restore'

Hi Jaswinder,

I'm not an expert in such things, but it appears that all the
unresolved symbols are of the form, "_pthread_*".  So it looks to me as
if
your program uses pthreads, but is not specifying that the program
should
be linked against the pthread library.

Just as a guess, try adding -lpthread to your compile line.

> Do You Yahoo!?
> 
> From homework help to love advice, Yahoo! Experts has your answer.
> http://experts.yahoo.com/

You may be interested to know that this Yahoo advertisement contravenes
RFC822, the standard for mail message exchange, because it starts the
line with "From ".  Starting a line with "From " indicates the start
of a new message.  If a message contains a From at the start of the
line, it should be escaped with ">", ie, ">From ".  

While I know there's nothing you can do about it, failure to quote
the "From " causes problems with many mail readers, such as Netscape,
which is what I use.

Regards,

Mitch.

Re: [linuxsh-dev] RPMs

[Jaswinder S. <jas...@ya...>]

Dear Stuart , Stephen and linuxsh-dev group,

I compiled simple C++ Hello world program as :-

sh-linux-gnu-g++ -ml -m3 hello.cpp

but i get :-

/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `istream::get(char &)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:91:
 undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:91:
 undefined reference to `_pthread_cleanup_pop_restore'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `istream::ignore(int, int)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:136
: undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:136
: undefined reference to
`_pthread_cleanup_pop_restore'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `istream::read(char *, int)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:152
: undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:152
: undefined reference to
`_pthread_cleanup_pop_restore'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `istream::operator>>(char &)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:211
: undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:583
: undefined reference to
`_pthread_cleanup_pop_restore'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `ostream::operator<<(unsigned int)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:594
: undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:594
: undefined reference to
`_pthread_cleanup_pop_restore'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `ostream::operator<<(long)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:610
: undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:610
: undefined reference to
`_pthread_cleanup_pop_restore'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libstdc++.a(iostream.
o): In function `ostream::operator<<(unsigned long)':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:621
: undefined reference to `_pthread_cleanup_push_defer'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/libio/iostream.cc:621
: undefined reference to `_pthread_cleanup_pop_restore
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/gcc/libgcc2.c(.text+0
x130): undefined reference to `pthread_setspecific'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libgcc.a(_eh.o):
In f
unction `eh_threads_initialize':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/gcc/libgcc2.c(.text+0
x1e4): undefined reference to `pthread_key_create'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libgcc.a(_eh.o):
In f
unction `eh_context_initialize':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/gcc/libgcc2.c(.text+0
x260): undefined reference to `pthread_once'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libgcc.a(_eh.o):
In f
unction `eh_context_specific':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/gcc/libgcc2.c(.text+0
x318): undefined reference to `pthread_getspecific'
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/gcc/libgcc2.c(.text+0
x324): undefined reference to `pthread_setspecific'
/opt/hardhat/devkit/sh/sh3/lib/gcc-lib/sh-linux-gnu/2.95.2/libgcc.a(_eh.o):
In f
unction `__default_terminate':
/home/heywood/users/thomass/testbuild-0.2/BUILD/gcc-2.95.2/gcc/libgcc2.c(.data+0
x0): undefined reference to `pthread_create'
collect2: ld returned 1 exit status    

---------

Please advice me, what to do .

Thank you very much for your help .

Best Regards,

Jaswinder.

--- Stuart Menefy <Stu...@st...> wrote:
> Folks
> 
> I'm happy to announce that we have finally released
> a set of RPMs for the
> SuperH. These include all the basic development
> tools for an x86 Linux PC,
> and most of the program you would want for an
> embedded target system.
> This is based on the MontaVista HardHat
> distribution.
> 
> For more details, please see the SourceForge web
> page:
>   http://linuxsh.sourceforge.net/docs/shrpm.php3
> 
> Most of the hard work getting this running on the
> SuperH has been done
> by Stephen Thomas (ste...@st...). Any
> comments, please let
> him or me know.
> 
> Stuart
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
>
http://lists.sourceforge.net/mailman/listinfo/linuxsh-dev


__________________________________________________
Do You Yahoo!?
From homework help to love advice, Yahoo! Experts has your answer.
http://experts.yahoo.com/

Re: [linuxsh-dev] New toolchain

[Rene M. <re...@li...>]

NIIBE Yutaka wrote:
> 
> kaz Kojima wrote:
>  > I'd like to report the status of new toolchain. They are stable and
>  > some weird bugs (especially in compiler) are eliminated.
> 
> Thanks a lot for the effort of everyone, especially Kaz and RedHat people.
> 
> For your convinience (or nightmare ;-), I've put the sources at ftp.m17n.org.
> 
>     ftp.m17n.org:/pub/super-h/original/
>         binutils-001005.tar.gz
>         egcs-core-20001002.tar.gz
> 
> And my patches (including Kaz'):
> 
>     ftp.m17n.org:/pub/super-h/
>         binutils-001005.diff.gz  (so that we can still use '$': Backward compatibility)
>         gcc-200010002.diff.gz
> 
> Please test these tools for kernel.  I'm now testing GNU C library 2.1.96...


I did find som debian packages on the site (in the debian directory) are
these the same. And if so are they patched (didnt look so but asking
anyhow)? 

I did compile the kernel with these tools and it vent fine up to a
point.
And I suspect that that isn't gcc related.

/Rene

Re: [linuxsh-dev] New toolchain

[Jaswinder S. <jas...@ya...>]

Dear Niibe-san , Kojima-san and linuxsh-dev group ,

--- NIIBE Yutaka <gn...@ch...> wrote:
> 
> For your convinience (or nightmare ;-), I've put the
> sources at ftp.m17n.org.
> 
>     ftp.m17n.org:/pub/super-h/original/
> 	binutils-001005.tar.gz
> 	egcs-core-20001002.tar.gz
> 
> And my patches (including Kaz'):
> 
>     ftp.m17n.org:/pub/super-h/
> 	binutils-001005.diff.gz  (so that we can still use
> '$': Backward compatibility)
> 	gcc-200010002.diff.gz
> 
> Please test these tools for kernel.  I'm now testing
> GNU C library 2.1.96...

That nice :-) 

and what about C++ support ? 

Thanks ,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

[linuxsh-dev] New toolchain

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

kaz Kojima wrote:
 > I'd like to report the status of new toolchain. They are stable and
 > some weird bugs (especially in compiler) are eliminated.

Thanks a lot for the effort of everyone, especially Kaz and RedHat people.

For your convinience (or nightmare ;-), I've put the sources at ftp.m17n.org.

    ftp.m17n.org:/pub/super-h/original/
	binutils-001005.tar.gz
	egcs-core-20001002.tar.gz

And my patches (including Kaz'):

    ftp.m17n.org:/pub/super-h/
	binutils-001005.diff.gz  (so that we can still use '$': Backward compatibility)
	gcc-200010002.diff.gz

Please test these tools for kernel.  I'm now testing GNU C library 2.1.96...
-- 

[linuxsh-dev] touch-panel drivers

[Jaswinder S. <jas...@ya...>]

Hi folks,

I am interested in touch-panel drivers . 

Can you tell me some links on the net for the sources
of the touch-panel driver for linux or unix machine
for any platform.

Thank you for your help.

Best Regards,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Re: [linuxsh-dev] Strip $ from registers in assembly

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

Jesper Skov wrote:
 > Problem is, you are probably not going to get that patch
 > accepted. From what I heard the tool people disliked the use of a $
 > prefix.

Yup, I know. :-)  In some environment, we cau use '$' in the label (VMS?).

Well, it seems for me that using '$' is just my preference.  All that
we have are sh-ipl+g and the kernel, and we have your patch for the
kernel.  In this condition, I could change not using '$' for our code.
This should be the last change, though.  I'll wait, say, for a week
for the opinion.

 > What I did is make the kernel build with the tools we have available.
 > Which is a priority to me - I'm a kernel hacker, not a tool smith.

I see.  In the (little) history of GNU/Linux port to SuperH, we've
been hacking the tools more than kernel, you see.  I hope it will be
changed soon (in a month or so).
-- 

Re: [linuxsh-dev] Strip $ from registers in assembly

[Jesper S. <js...@re...>]

>>>>> "NIIBE" == NIIBE Yutaka <gn...@ch...> writes:

NIIBE> I have work-around patch for binutils (it's not properly
NIIBE> implemented):

Problem is, you are probably not going to get that patch
accepted. From what I heard the tool people disliked the use of a $
prefix. Don't know what you were told before - and it's not really my
business to tell you either way.

What I did is make the kernel build with the tools we have available.
Which is a priority to me - I'm a kernel hacker, not a tool smith.

Jesper

[linuxsh-dev] New toolchain

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

Hi all,

I'd like to report the status of new toolchain. They are stable and
some weird bugs (especially in compiler) are eliminated.
Now the sources of new toolchain are available, but I should explain
other things first before listing up the resources.

1) There are some differences with current toolchain.

New gcc and binutils are brushed up by peoples mainly in Red Hat and
they changed some features of our experimental ports which are basically
equal to existing ports in SourceForge.

The major differences are the followings:

  * New gcc doesn't generate register prefix $.
  * New as doesn't permit register prefix.
  * New as doesn't need -pic option.
  * New ld uses in place relocation for R_SH_RELATIVE relocation
    in shared object. (The old ld uses addend field for it.)

The last one results the binary incompatibility problem. So we prepare
compatibility patches for new ld and dynamic linker in GNU libc. (These
relocations appear only in shared library, fortunately :-))
The patch for new ld doesn't change the behavior of new ld but clears
addend field of the relocation in problem. Then the dynamic linker can
detect whether a shared library uses relocations of old type or not. Now
I'm using the mixture of the old and new binaries and libraries and there
is no problem. The patch for dynamic linker is included in mainline libc
source already.
This incompatibility makes the install of new toolchain in native
system hard. I recommend that

  * make new binutils and gcc and install them not as system binary.
    (You can use --prefix option at configuration.)
  * make libc with new toolchain. If you get success, then install it.
  * make new toolchain to system binaries.

for brave testers who use SH native system. But if you want to know more
details, never try it :-) To be honest, I made mistakes in such process
and the result was very disastrous.
I think that we should prepare the binary package in SourceForge.

The second deference will affects hand-crafted codes. Of course, we can
give a tiny local patch which turns this difference simply (like as
Niibe-san's patch) or permits $ but warning for it.

2) A few small patches are still waiting.

Niibe-san and I posted a few tiny patches to new toolchain. But they
are not included in mainline sources yet.

3) A native GDB support.

New toolchain doesn't have any native GDB support. I have a very
experimental patch for it.

4) Resources.

GCC:
  http://gcc.gnu.org/cvs.html
GNU binutils:
  http://sources.redhat.com/binutils/
GNU libc:
  http://sources.redhat.com/glibc/
GDB:
  http://sources.redhat.com/gdb/

Please remember these CVS resources (especially GCC) are not stable
version.

About local patches and a temporary native GDB support, see
  http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/temporary-README-new-toolchain

	kaz

Re: [linuxsh-dev] A couple of minor fixes

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

NIIBE Yutaka wrote:
> 
>  >      * drivers/pcmcia/cs.c: Missing rename.
> 
> It's out of my scope.  Could you please send it to PCMCIA maintainer?

  The problem fixed by this patch is already fixed in the latest PCMCIA
source (3.1.20), so sending it to David Hinds will not achieve anything.

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] Strip $ from registers in assembly

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

Jesper Skov wrote:
 > The below patch removes all use of $-prefixed register names. This is
 > necessary for the next version of binutils (as far as I know) and
 > should be harmless for the older versions - at least non-prefixed
 > register names get used a few places as well.

Thanks.  I have not decided yet, this patch is installed or not.

The history of "$" is like follows:

(1) Last year, when I and Kaz define ABI for GNU/Linux on
    SuperH, there came the feedback from Cygnus, we would need to
    change register description (prepending $ or something) so
    that the assembler can distingush label and the register

(2) We've changed the binutils and all our code base to use
   '$' prepended.  IMHO, it looks better.

(3) RedHat implemented our ABI in binutils, without the '$' register
    description.  I think that it has restriction, where label cannot
    use "r0", "gbr" or something like that.

I have work-around patch for binutils (it's not properly implemented):

Put the definition in gcc/config/sh/linux.h
------------
#define REGISTER_PREFIX "$"
------------

--- binutils/gas/config/tc-sh.c.orig	Sat Sep  2 11:36:27 2000
+++ binutils/gas/config/tc-sh.c	Wed Sep 27 13:12:08 2000
@@ -459,7 +459,7 @@ sh_operand_info;
 /* Try to parse a reg name.  Return the number of chars consumed.  */
 
 static int
-parse_reg (src, mode, reg)
+parse_reg_without_prefix (src, mode, reg)
      char *src;
      int *mode;
      int *reg;
@@ -804,6 +804,26 @@ parse_reg (src, mode, reg)
 
   return 0;
 }
+
+static int
+parse_reg (src, mode, reg)
+     char *src;
+     int *mode;
+     int *reg;
+{
+  int prefix;
+
+  if (src[0] == '$')
+    {
+      src++;
+      prefix = 1;
+    }
+  else
+    prefix = 0;
+
+  return prefix + parse_reg_without_prefix (src, mode, reg);
+}
+
 
 static symbolS *
 dot ()

-- 

[linuxsh-dev] A couple of minor fixes

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

Jesper Skov wrote:
 > 2000-09-28  Jesper Skov  <js...@re...>
 > 
 > 	* arch/sh/kernel/time.c: The loop align seemed to have gone
 >           AWOL in the last merge.

Weird.  I have ".align 2".  Please check it.

 > 	* drivers/pcmcia/cs.c: Missing rename.

It's out of my scope.  Could you please send it to PCMCIA maintainer?
-- 

[linuxsh-dev] RPMs

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

Folks

I'm happy to announce that we have finally released a set of RPMs for the
SuperH. These include all the basic development tools for an x86 Linux PC,
and most of the program you would want for an embedded target system.
This is based on the MontaVista HardHat distribution.

For more details, please see the SourceForge web page:
  http://linuxsh.sourceforge.net/docs/shrpm.php3

Most of the hard work getting this running on the SuperH has been done
by Stephen Thomas (ste...@st...). Any comments, please let
him or me know.

Stuart

[linuxsh-dev] Re: [linux-sh:01352] Re: Debian GNU/Linux on Dreamcast

[Werner C. <cor...@is...>]

Rene Malmgren wrote:
> 
> Werner Cornelius wrote:
> >
> > I didn't found any shop delivering NEOGEO <-> DC Link cables. And the
> > shop directly offering programming cables in Hongkong is still not able
> > to deliver the cable.
> 
> Funny I ordered the NEOGEO <-> DC Link cable from Hong Kong lest week,
> and I got it in the mail yesterday (so yes It works). So I'll be
> converting things this weekend. Have you tried David's Console Shop at
> http://www.dcshk.com/select_dc.htm, there you can order the NEOGEO cable
> (art DC-0018), While I was at it I also ordered a VGA cable (art
> DC-0019) to be able to connect my DC to my 14" VGA monitor. It works
> just fine (now I can read the text from the DC console ;-) ) the total
> price was 59$ (22 for the cable and 37 for the NEOGEO) including
> shipment to Sweden it took about 7 days to deliver.
> 

Some hours before I ordered the needed cables and a memory card (I don't
know if I really need it some time, I am not playing games) from another
Hongkong dealer. There a direct PC link cable is announced and I hope it
will be released in the next 2 weeks.
Other artcles are a bit cheaper than at Davids Console Shop like I just
compared. 
The domain is lik-sang.com, I hope there are no problems getting the
things to europe.
None of those dealers offers single connectors or similar things which
would be very useful.

But thanks for your tip.

Werner
     

> /Rene

[linuxsh-dev] A couple of minor fixes

[Jesper S. <js...@re...>]

2000-09-28  Jesper Skov  <js...@re...>

	* arch/sh/kernel/time.c: The loop align seemed to have gone
          AWOL in the last merge.
	* drivers/pcmcia/cs.c: Missing rename.


Index: arch/sh/kernel/time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.17
diff -u -5 -r1.17 time.c
--- arch/sh/kernel/time.c	2000/10/27 01:14:20	1.17
+++ arch/sh/kernel/time.c	2000/10/27 11:28:50
@@ -335,10 +335,11 @@
 
 	sti();
 	do {} while (ctrl_inb(R64CNT) != 0);
 	ctrl_outb(RCR1_CIE, RCR1); /* Enable carry interrupt */
 	asm volatile(
+		".align2\n\t"
 		"1:\t"
 		"tst	%1,%1\n\t"
 		"bt/s	1b\n\t"
 		" add	#1,%0"
 		: "=r"(count), "=z" (__dummy)


Index: drivers/pcmcia/cs.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/pcmcia/cs.c,v
retrieving revision 1.9
diff -u -5 -r1.9 cs.c
--- drivers/pcmcia/cs.c	2000/10/27 07:21:17	1.9
+++ drivers/pcmcia/cs.c	2000/10/27 11:29:01
@@ -1834,11 +1834,11 @@
     when the configuration is locked.  Now that I think about it,
     there might be a way to fix this using a dummy handler.
     
 ======================================================================*/
 
-static int cs_request_irq(client_handle_t handle, irq_req_t *req)
+int pcmcia_request_irq(client_handle_t handle, irq_req_t *req)
 {
     socket_info_t *s;
     config_t *c;
     int ret = 0, irq = 0;
     
@@ -1900,11 +1900,11 @@
     s->irq.Config++;
     
     c->state |= CONFIG_IRQ_REQ;
     handle->state |= CLIENT_IRQ_REQ;
     return CS_SUCCESS;
-} /* cs_request_irq */
+} /* pcmcia_request_irq */
 
 /*======================================================================
 
     Request_window() establishes a mapping between card memory space
     and system memory space.

[linuxsh-dev] Strip $ from registers in assembly

[Jesper S. <js...@re...>]

Heya

The below patch removes all use of $-prefixed register names. This is
necessary for the next version of binutils (as far as I know) and
should be harmless for the older versions - at least non-prefixed
register names get used a few places as well.

Note that I also changed the varargs-macros to comply with the cpp
documentation (the old format is obsolete). This required the
-traditional flag to be removed when assembling the files via gcc.

Jesper

[linuxsh-dev] Re: [linux-sh:01352] Re: Debian GNU/Linux on Dreamcast

[Rene M. <re...@li...>]

Werner Cornelius wrote:
> 
> Dan Potter schrieb:
> >
> > I recall waay back on Oct 27 when Werner Cornelius wrote:
> >
> > > I just cracked partially the pinout of the SEGA custom chip 315-6137
> > > inside the modem card.
> > > Together with the data sheet of the mode chip I found out how I could
> > > replace the modem chip by other hardware, if I find the time I will
> > > connect an ethernet board this weekend.
> >
> > Wow, you're fast!
> 
> It took me about one and a half day where the infos on the internet were
> very helpfull.
> But now the whole thing seems to stagnate.
> I didn't found any shop delivering NEOGEO <-> DC Link cables. And the
> shop directly offering programming cables in Hongkong is still not able
> to deliver the cable.

Funny I ordered the NEOGEO <-> DC Link cable from Hong Kong lest week,
and I got it in the mail yesterday (so yes It works). So I'll be
converting things this weekend. Have you tried David's Console Shop at
http://www.dcshk.com/select_dc.htm, there you can order the NEOGEO cable
(art DC-0018), While I was at it I also ordered a VGA cable (art
DC-0019) to be able to connect my DC to my 14" VGA monitor. It works
just fine (now I can read the text from the DC console ;-) ) the total
price was 59$ (22 for the cable and 37 for the NEOGEO) including
shipment to Sweden it took about 7 days to deliver. 

/Rene

[linuxsh-dev] Re: [linux-sh:01348] Re: Debian GNU/Linux on Dreamcast

[M. R. B. <ma...@uw...>]

On Fri, 27 Oct 2000, YAEGASHI Takeshi wrote:

> In the article <Pin...@al...>,
> "M. R. Brown" <ma...@uw...> wrote:
> 
> > Marcus Comstedt (http://mc.pp.se/dc/), Dan Potter (from this list) and
> > others on the dcdev list (at egroups) have exposed a lot of the
> > information necessary to write kernel drivers for various DC subsystems.
> > Info is available for:
> >   - Video modes: 320x240 565, 640x480 565, and 640x480 888.  That means a
> >     decent (albeit slow?) framebuffer can be constructed.
> >   - CD-ROM subsystem support.
> >   - Audio: I was thinking maybe a "generic" AICA firmware to emulate OSS
> >     or else a DC-specific audio spec.
> >   - Input: The DC's maple bus is spec'd, meaning keyboards, mice,
> >     controllers, VMUs are all avail.  The keyboard+fb is especially
> >     enticing.
> >   - Dan Potter has done some work regarding 2D-acceleration on the NEC
> >     PVR.  I haven't gotten a chance to really investigate this, but he
> >     suggested an accelerated framebuffer.
> >
> > This is more than enough for us "hobbyists" to get started, other things
> > that could come later would be the expansion port (which gives us modem
> > and ethernet - eventually), better 3D support, etc.
> 
> Yes, their works are really great.  But I think they're
> insufficient for writing kernel drivers.  I need specs of
> hardware registers, not BIOS calls.  Specs of interrupt and DMA
> handling are particularly important.
> 

AFAIK, only the CD/GD-ROM subsystem uses BIOS calls, and that could be
"liberated" with a little clean room reverse engineering :).  The
framebuffer, sound, and maple bus could easily be implemented in the
kernel with current information (I hope).  I'm currently studying the SH4
manuals to get up to speed, etc. 

> 
> > It's cool that a licensed DC developer has ported Linux, but IMHO it would
> > benefit the community if hobbyists undertook this and got the kernel
> > stable on DC.  I'm very interested in pursuing this, anyone else up for
> > the challenge? :)
> 
> Oh yes.  I would release my port as soon as possible if I was
> not an employee of NAMCO.
> 
> Actually, I'm nothing more than one of the hobbyist developers.
> My business has nothing to do with Dreamcast, I've never seen
> Dreamcast's SDK.
>

Me neither, and I hope to never see one :).
 
> --
> YAEGASHI Takeshi <yae...@ma...>
> 
> 

M. R. Brown

[linuxsh-dev] Re: [linux-sh:01343] Re: Debian GNU/Linux on Dreamcast

[YAEGASHI T. <yae...@ma...>]

Hello all,

Sorry for late and short reply.  It costs me so long time to
write in English. :->

In the article <Pin...@al...>,
"M. R. Brown" <ma...@uw...> wrote:

> Marcus Comstedt (http://mc.pp.se/dc/), Dan Potter (from this list) and
> others on the dcdev list (at egroups) have exposed a lot of the
> information necessary to write kernel drivers for various DC subsystems.
> Info is available for:
>   - Video modes: 320x240 565, 640x480 565, and 640x480 888.  That means a
>     decent (albeit slow?) framebuffer can be constructed.
>   - CD-ROM subsystem support.
>   - Audio: I was thinking maybe a "generic" AICA firmware to emulate OSS
>     or else a DC-specific audio spec.
>   - Input: The DC's maple bus is spec'd, meaning keyboards, mice,
>     controllers, VMUs are all avail.  The keyboard+fb is especially
>     enticing.
>   - Dan Potter has done some work regarding 2D-acceleration on the NEC
>     PVR.  I haven't gotten a chance to really investigate this, but he
>     suggested an accelerated framebuffer.
>
> This is more than enough for us "hobbyists" to get started, other things
> that could come later would be the expansion port (which gives us modem
> and ethernet - eventually), better 3D support, etc.

Yes, their works are really great.  But I think they're
insufficient for writing kernel drivers.  I need specs of
hardware registers, not BIOS calls.  Specs of interrupt and DMA
handling are particularly important.


> It's cool that a licensed DC developer has ported Linux, but IMHO it would
> benefit the community if hobbyists undertook this and got the kernel
> stable on DC.  I'm very interested in pursuing this, anyone else up for
> the challenge? :)

Oh yes.  I would release my port as soon as possible if I was
not an employee of NAMCO.

Actually, I'm nothing more than one of the hobbyist developers.
My business has nothing to do with Dreamcast, I've never seen
Dreamcast's SDK.

--
YAEGASHI Takeshi <yae...@ma...>

[linuxsh-dev] Remove ioremap_nocache from machine vector

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

I think that we don't need ioremap_nocache API.  We see it in the
MIPS port, but I don't know the drivers which uses it.

2000-10-27  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/kernel/mach_unknown.c (mv_ioremap_nocache): Removed.
	* arch/sh/kernel/mach_se.c (mv_ioremap_nocache): Removed.
	* arch/sh/kernel/io_unknown.c (ioremap_nocache): Removed.
	* arch/sh/kernel/io_generic.c (generic_ioremap_nocache): Removed.

	* include/asm-sh/io_unknown.h (unknown_ioremap_nocache,
	__ioremap_nocache): Removed.
	* include/asm-sh/io_se.h (__ioremap_nocache): Removed.
	* include/asm-sh/io_od.h (__ioremap_nocache): Removed.
	* include/asm-sh/io_hd64465.h (__ioremap_nocache): Removed.
	* include/asm-sh/io_generic.h (generic_ioremap_nocache): Removed.
	* include/asm-sh/io.h (__ioremap_nocache): Removed.
	* include/asm-sh/io.h (ioremap_nocache): Removed.
	* include/asm-sh/machvec.h (struct sh_machine_vector): Removed
	ioremap_nocache.

Index: include/asm-sh/io.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io.h,v
retrieving revision 1.8
diff -u -p -r1.8 io.h
--- include/asm-sh/io.h	2000/10/12 07:29:21	1.8
+++ include/asm-sh/io.h	2000/10/27 02:25:45
@@ -70,7 +70,6 @@
 # define __writel(v,a)	sh_mv.mv_writel((v),(a))
 
 # define __ioremap(a,s)	sh_mv.mv_ioremap((a), (s))
-# define __ioremap_nocache(a,s)	sh_mv.mv_ioremap_nocache((a), (s))
 # define __iounmap(a)	sh_mv.mv_iounmap((a))
 
 # define __isa_port2addr(a)	sh_mv.mv_isa_port2addr(a)
@@ -412,16 +411,6 @@ extern __inline__ void * phys_to_virt(un
 static __inline__ void * ioremap(unsigned long offset, unsigned long size)
 {
 	return __ioremap(offset, size);
-}
-
-/*
- * This one maps high address device memory and turns off caching for that area.
- * it's useful if some control registers are in such an area and write combining
- * or read caching is not desirable:
- */
-static __inline__ void * ioremap_nocache (unsigned long offset, unsigned long size)
-{
-	return __ioremap_nocache(offset, size);
 }
 
 static __inline__ void iounmap(void *addr)
Index: include/asm-sh/io_generic.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io_generic.h,v
retrieving revision 1.3
diff -u -p -r1.3 io_generic.h
--- include/asm-sh/io_generic.h	2000/08/05 06:25:25	1.3
+++ include/asm-sh/io_generic.h	2000/10/27 02:25:45
@@ -44,7 +44,6 @@ extern void generic_writew(unsigned shor
 extern void generic_writel(unsigned int b, unsigned long addr);
 
 extern void *generic_ioremap(unsigned long offset, unsigned long size);
-extern void *generic_ioremap_nocache (unsigned long offset, unsigned long size);
 extern void generic_iounmap(void *addr);
 
 extern unsigned long generic_isa_port2addr(unsigned long offset);
Index: include/asm-sh/io_hd64465.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io_hd64465.h,v
retrieving revision 1.2
diff -u -p -r1.2 io_hd64465.h
--- include/asm-sh/io_hd64465.h	2000/10/16 05:19:34	1.2
+++ include/asm-sh/io_hd64465.h	2000/10/27 02:25:45
@@ -81,7 +81,6 @@ extern void hd64465_port_unmap(unsigned 
 
 # define __isa_port2addr	hd64465_isa_port2addr
 # define __ioremap		generic_ioremap
-# define __ioremap_nocache	generic_ioremap_nocache
 # define __iounmap		generic_iounmap
 
 
Index: include/asm-sh/io_od.h
===================================================================
Index: arch/sh/kernel/io_generic.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/io_generic.c,v
retrieving revision 1.9
diff -u -p -r1.9 io_generic.c
--- arch/sh/kernel/io_generic.c	2000/10/16 05:03:30	1.9
+++ arch/sh/kernel/io_generic.c	2000/10/27 02:25:43
@@ -188,12 +188,6 @@ void * generic_ioremap(unsigned long off
 }
 EXPORT_SYMBOL(generic_ioremap);
 
-void * generic_ioremap_nocache (unsigned long offset, unsigned long size)
-{
-	return (void *) P2SEGADDR(offset);
-}
-EXPORT_SYMBOL(generic_ioremap_nocache);
-
 void generic_iounmap(void *addr)
 {
 }
Index: arch/sh/kernel/io_unknown.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/io_unknown.c,v
retrieving revision 1.2
diff -u -p -r1.2 io_unknown.c
--- arch/sh/kernel/io_unknown.c	2000/08/05 06:25:23	1.2
+++ arch/sh/kernel/io_unknown.c	2000/10/27 02:25:43
@@ -43,5 +43,4 @@ UNKNOWN_ALIAS(writew)
 UNKNOWN_ALIAS(writel)
 UNKNOWN_ALIAS(isa_port2addr)
 UNKNOWN_ALIAS(ioremap)
-UNKNOWN_ALIAS(ioremap_nocache)
 UNKNOWN_ALIAS(iounmap)
Index: arch/sh/kernel/mach_se.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_se.c,v
retrieving revision 1.2
diff -u -p -r1.2 mach_se.c
--- arch/sh/kernel/mach_se.c	2000/08/23 01:36:49	1.2
+++ arch/sh/kernel/mach_se.c	2000/10/27 02:25:43
@@ -65,7 +65,6 @@ struct sh_machine_vector mv_se __initmv 
 	mv_writel:		se_writel,
 
 	mv_ioremap:		generic_ioremap,
-	mv_ioremap_nocache:	generic_ioremap_nocache,
 	mv_iounmap:		generic_iounmap,
 
 	mv_isa_port2addr:	se_isa_port2addr,
Index: arch/sh/kernel/mach_unknown.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/mach_unknown.c,v
retrieving revision 1.2
diff -u -p -r1.2 mach_unknown.c
--- arch/sh/kernel/mach_unknown.c	2000/08/23 01:36:49	1.2
+++ arch/sh/kernel/mach_unknown.c	2000/10/27 02:25:43
@@ -61,7 +61,6 @@ struct sh_machine_vector mv_unknown __in
 	mv_writel:		unknown_writel,
 
 	mv_ioremap:		unknown_ioremap,
-	mv_ioremap_nocache:	unknown_ioremap_nocache,
 	mv_iounmap:		unknown_iounmap,
 
 	mv_isa_port2addr:	unknown_isa_port2addr,
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io_od.h,v
retrieving revision 1.2
diff -u -p -r1.2 io_od.h
--- include/asm-sh/io_od.h	2000/08/01 03:18:39	1.2
+++ include/asm-sh/io_od.h	2000/10/27 02:25:45
@@ -70,7 +70,6 @@ extern unsigned long od_isa_port2addr(un
 
 # define __isa_port2addr	od_isa_port2addr
 # define __ioremap		generic_ioremap
-# define __ioremap_nocache	generic_ioremap_nocache
 # define __iounmap		generic_iounmap
 
 #endif
Index: include/asm-sh/io_se.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io_se.h,v
retrieving revision 1.2
diff -u -p -r1.2 io_se.h
--- include/asm-sh/io_se.h	2000/08/01 03:18:39	1.2
+++ include/asm-sh/io_se.h	2000/10/27 02:25:45
@@ -73,7 +73,6 @@ extern unsigned long se_isa_port2addr(un
 
 # define __isa_port2addr	se_isa_port2addr
 # define __ioremap		generic_ioremap
-# define __ioremap_nocache	generic_ioremap_nocache
 # define __iounmap		generic_iounmap
 
 #endif
Index: include/asm-sh/io_unknown.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io_unknown.h,v
retrieving revision 1.2
diff -u -p -r1.2 io_unknown.h
--- include/asm-sh/io_unknown.h	2000/08/01 03:18:39	1.2
+++ include/asm-sh/io_unknown.h	2000/10/27 02:25:45
@@ -43,7 +43,6 @@ extern void unknown_writel(unsigned int 
 
 extern unsigned long unknown_isa_port2addr(unsigned long offset);
 extern void * unknown_ioremap(unsigned long offset, unsigned long size);
-extern void * unknown_ioremap_nocache (unsigned long offset, unsigned long size);
 extern void unknown_iounmap(void *addr);
 
 #ifdef __WANT_IO_DEF
@@ -78,7 +77,6 @@ extern void unknown_iounmap(void *addr);
 
 # define __isa_port2addr	unknown_isa_port2addr
 # define __ioremap		unknown_ioremap
-# define __ioremap_nocache	unknown_ioremap_nocache
 # define __iounmap		unknown_iounmap
 
 #endif
Index: include/asm-sh/machvec.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/machvec.h,v
retrieving revision 1.3
diff -u -p -r1.3 machvec.h
--- include/asm-sh/machvec.h	2000/10/12 07:29:21	1.3
+++ include/asm-sh/machvec.h	2000/10/27 02:25:45
@@ -48,7 +48,6 @@ struct sh_machine_vector
 	void (*mv_writel)(unsigned int, unsigned long);
 
 	void* (*mv_ioremap)(unsigned long offset, unsigned long size);
-	void* (*mv_ioremap_nocache)(unsigned long offset, unsigned long size);
 	void (*mv_iounmap)(void *addr);
 
 	unsigned long (*mv_port2addr)(unsigned long offset);

-- 

[linuxsh-dev] Fix timing loop

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

Jesper Skov wrote:
 > This is the accuracy fix I mentioned the other day.

Just has been installed.  Thanks.
-- 

[linuxsh-dev] BareCPU build patch/sh_ksyms.c warning patch

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

Bryan Rittmeyer writes:
 > When trying to build the latest CVS kernel with a machine type of
 > "BareCPU" the build fails on setup.c:
[...]
 > This error is because there is no extern declaration for mv_unknown when
 > building with CONFIG_SH_UNKNOWN. Here's my patch, which I believe is
 > correct:
[...]

 > I also made a stupid mistake on my previous sh_ksyms.c patch by using
 > "arch/sh/lib/*.S" inside of a comment. The compiler sees "/*" and warns
 > about a comment inside of a comment. Here's the fix:

Thanks.  Comment just removed.  mv_unknown declared.
--