linuxsh-dev

[linuxsh-dev] non volatile memory for SH3

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

Hello,

1) I'm going to buy some non volitale memory for my EBX7709 development
board working with SH3.
The memory has to be a PC-Card, because I want to connect it via PCMCIA
interface. In future it should be possible to mount a file system on this
FLASH Card. Could somebody recommend me such a FLASH memory? I think, there
are two main possibilities:
- Compact FLASH or
- FlashDrive

Which is easier to use with SH3? I hope to use an existing PCMCIA patches
for SH3 without porting any other drivers.
Could you share your experience with this problem?

2) With the same PCMCIA interface, I'm going to connect a network card
(NE2000 compatible). Does somebody works with similar hardware
configuration? Which kernel? do I have to use moduitls?


regards
Pawel

Re: [linuxsh-dev] Lazy FPU switching

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

Dear Jesper,

--- Jesper Skov <js...@re...> wrote:
> 
> If I'm not mistaken, the SH implementation of lazy
> FPU switching isn't
> really lazy. It always saves the FPU state on a
> context switch:
>

yes , you are right but i think this is OK for SH
implementation.

> 
> I don't know if lazy switching is suitable for
> embedded targets (the
> goal being performance). 

Actually , we do not want embedded systems to get lazy
.Though they do not work as hard-real time but we
expect them as close as soft-real time . And i think
Niibe-san and Kojima-san are aware of this issue ,
thats why they do like this :-)

>Probably would make sense
> to clear out the
> FPU when not used, allowing the FPU circuitry to be
> powered down [if
> that's possible in the SH4 CPUs].
>

I think this is not possble because FPU are useful for
geometric operations instructions , single-precision
transfer instructions that enable high-speed data
transfer and of course for floating points as pointed
by Greg.

> Just my $.02 having happened to read the code. I
> don't have a SH4
> board myself.
>

i see . let i make one annoucement :-)

Ladies and Gentlemen , is any body interested to
donate their spare SH4 board , you are welcome . Thank
you very much for your interest.

I hope , this will work :-)

Best Regards.

Jaswinder.

> Cheers,
> Jesper


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

Re: [linuxsh-dev] touch-panel drivers

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

Dear James Simmons,

--- James Simmons <jsi...@su...> wrote:
> 
> > 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.
> 
> Their exist support already for this (Guze AHL-51S
> touchscreen). This is
> considered a input suite driver (/dev/event). 
> 
> .
> r (/dev/event). 
> 
> .
> 

Thanks , but where can i get sources and technical
specs for such touchscreen , please tell me such links
 on the net , if exists .

thanks ,

Best Regards,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

[linuxsh-dev] [PATCH] better module clock calibration

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

I just submitted a patch to sourceforge that changes our clock calibration
mechanism to calibrate the timer clock rather than the CPU clock;  this
means it is more portable now (no assembly, and no CPU-specific constant);
it's also much faster (1/128 - 1/64 second rather than 1 - 2 seconds),
while not losing a lot of accuracy.

The original version also included a version of gettimeoffset, but the one
SUGIOKA Toshinobu has written at the same time as I is nicer.

There is also a very slight bugfix which I would like to paste here:

        /* Start TMU0 */
+       ctrl_outb(0, TMU_TSTR);
        ctrl_outb(TMU_TOCR_INIT, TMU_TOCR);
        ctrl_outw(TMU0_TCR_INIT, TMU0_TCR);
        ctrl_outl(interval, TMU0_TCOR);

Without this, the kernel wouldn't boot correctly if TMU0 was already
started.  Since head.S says:

 *   Hardware (including on-chip modules) may or may not be initialized. 

this sounds like the right thing to do to me.

The updated version of the patch (against current CVS) is attached.

Re: [linuxsh-dev] Lazy FPU switching

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

Jesper Skov wrote:
> 
> If I'm not mistaken, the SH implementation of lazy FPU switching isn't
> really lazy. It always saves the FPU state on a context switch:
> 
> /*
>  *      switch_to(x,y) should switch tasks from x to y.
>  *
>  */
> void __switch_to(struct task_struct *prev, struct task_struct *next)
> {
> #if defined(__SH4__)
>         if (prev != &init_task) {
>                 unsigned long flags;
> 
>                 save_and_cli(flags);
>                 unlazy_fpu(prev);
>                 restore_flags(flags);
>         }
> #endif
>         /*
>          * Restore the kernel mode register
>          *      k7 (r7_bank1)
>          */
>         asm volatile("ldc       %0, r7_bank"
>                      : /* no output */
>                      :"r" (next));
> }
> 
> For it to work properly (lazy fashion) it should just clear the FD
> flag at that point, and have some magic in do_fpu_state_restore() to
> save the registers to the previous FPU using task before loading the
> FPU again. If that previous task is current, no saving/restoring is
> necessary.
> 
> I think the current implementation is probably due to being based on
> the i386 where (apparently) there's no gain in lazy switching.
> 
> I don't know if lazy switching is suitable for embedded targets (the
> goal being performance). Probably would make sense to clear out the
> FPU when not used, allowing the FPU circuitry to be powered down [if
> that's possible in the SH4 CPUs].
> 
> Just my $.02 having happened to read the code. I don't have a SH4
> board myself.

Heh.  Take a look at gcc-core/gcc/config/sh/lib1funcs.asm:udivsi3_i4.

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] Re: [linux-fbdev] touch-panel drivers

[James S. <jsi...@su...>]

> 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.

Their exist support already for this (Guze AHL-51S touchscreen). This is
considered a input suite driver (/dev/event). 

[linuxsh-dev] Lazy FPU switching

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

If I'm not mistaken, the SH implementation of lazy FPU switching isn't
really lazy. It always saves the FPU state on a context switch:



/*
 *	switch_to(x,y) should switch tasks from x to y.
 *
 */
void __switch_to(struct task_struct *prev, struct task_struct *next)
{
#if defined(__SH4__)
	if (prev != &init_task) {
		unsigned long flags;

		save_and_cli(flags);
		unlazy_fpu(prev);
		restore_flags(flags);
	}
#endif
	/*
	 * Restore the kernel mode register
	 *   	k7 (r7_bank1)
	 */
	asm volatile("ldc	%0, r7_bank"
		     : /* no output */
		     :"r" (next));
}



For it to work properly (lazy fashion) it should just clear the FD
flag at that point, and have some magic in do_fpu_state_restore() to
save the registers to the previous FPU using task before loading the
FPU again. If that previous task is current, no saving/restoring is
necessary.

I think the current implementation is probably due to being based on
the i386 where (apparently) there's no gain in lazy switching.


I don't know if lazy switching is suitable for embedded targets (the
goal being performance). Probably would make sense to clear out the
FPU when not used, allowing the FPU circuitry to be powered down [if
that's possible in the SH4 CPUs].

Just my $.02 having happened to read the code. I don't have a SH4
board myself.

Cheers,
Jesper

Re: [linuxsh-dev] RPMs

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

Dear Steve Thomas,

Thanks for your help.

Best Regards,

Jaswinder.

--- stephen thomas <ste...@st...> wrote:
> This problem is caused by an error in the 'specs'
> used by the C++ compiler, 
> which results in the pthread library being omitted
> from the link. To get round 
> this, add:
> 
>     -lpthread
> 
> to the command line. We will fix this in the next
> release.
> 
> 
> Steve Thomas
> STMicroelectronics
> 
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: Re: [linuxsh-dev] RPMs
> Author:  jaswinderrajput (jas...@ya...)
> at internet
> Date:    11/2/00 5:32 AM
> 
> 
> 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/
> 


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

Re: [linuxsh-dev] RPMs

[stephen t. <ste...@st...>]

This problem is caused by an error in the 'specs' used by the C++ compiler, 
which results in the pthread library being omitted from the link. To get round 
this, add:

    -lpthread

to the command line. We will fix this in the next release.


Steve Thomas
STMicroelectronics


______________________________ Reply Separator _________________________________
Subject: Re: [linuxsh-dev] RPMs
Author:  jaswinderrajput (jas...@ya...) at internet
Date:    11/2/00 5:32 AM


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] trouble with sh-GCC "97" and CVS kernel

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

Dear Mitch ,

--- Mitch Davis <md...@po...> wrote:
> We are not working on any HP computer.
>

OK , then i will not disturb you ;-)
 
> > I need touch panel and sound specs of HP690
> machine or
> > other HP machine , can you give me some hint or
> idea .
> 
> I think some others on this list (Takeshi Yaegashi?)
> may
> be able to help you.
>

yes , you are right , but i think Yaegashi-san check
his mail only once or twice in a week , we both are
living in same city but i never see him even once ;-)


> Regards,
> 
> Mitch.
> .
> ou.
> 
> Regards,
> 
> Mitch.
> .
>

Wow , you look very excited 8-) what happen ?

Best Regards,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

Re: [linuxsh-dev] trouble with sh-GCC "97" and CVS kernel

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

Jaswinder Singh wrote:
> 
> Can you tell me something about your computer (if it
> is not under NDA :-)

Nothing is under NDA - all of the kernel work we are doing
will be released under GPL in good time.  But the details
of *which* computer we are working on is commercially
sensitive at this point.

> BTW, I am collecting information about whole HP
> Jornada series machines . That why i am disturbing you

We are not working on any HP computer.

> I need touch panel and sound specs of HP690 machine or
> other HP machine , can you give me some hint or idea .

I think some others on this list (Takeshi Yaegashi?) may
be able to help you.

Regards,

Mitch.

Re: [linuxsh-dev] trouble with sh-GCC "97" and CVS kernel

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

Dear Mitch,

--- Mitch Davis <md...@po...> wrote:
> Dear Jaswinder,
> 
> These companion chips are designed so you can put
> them into your design for a SuperH computer.  They
> are not restricted to a particular brand or model
> of computer.  I don't know where else the HD64465
> is used, only that there's one in the computer I'm
> currently working with.
>

Thanks , i understand this .

Can you tell me something about your computer (if it
is not under NDA :-)

BTW, I am collecting information about whole HP
Jornada series machines . That why i am disturbing you
.

I need touch panel and sound specs of HP690 machine or
other HP machine , can you give me some hint or idea .


Thanks .

Best Regards,

Jaswinder.

> Regards,
> 
> Mitch.


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

Re: [linuxsh-dev] trouble with sh-GCC "97" and CVS kernel

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

Jaswinder Singh wrote:
> 
> Dear Mitch ,
> 
> --- Mitch Davis <md...@po...> wrote:
> >
> >  ifneq ($(CONFIG_SH_GENERIC)$(CONFIG_HD64465),)
> > -O_OBJS += setup_hd64465.o io_hd64465.o
> > hd64465_gpio.o
> > +O_OBJS += setup_hd64465.o io_hd64465.o
> >  endif
> 
> I know that hd64461 is for HP680/690 but can you tell
> hd64465 is for which machine .

Dear Jaswinder,

These companion chips are designed so you can put
them into your design for a SuperH computer.  They
are not restricted to a particular brand or model
of computer.  I don't know where else the HD64465
is used, only that there's one in the computer I'm
currently working with.

Regards,

Mitch.

Re: [linuxsh-dev] trouble with sh-GCC "97" and CVS kernel

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

Dear Mitch ,

--- Mitch Davis <md...@po...> wrote:
>  
>  ifneq ($(CONFIG_SH_GENERIC)$(CONFIG_HD64465),)
> -O_OBJS += setup_hd64465.o io_hd64465.o
> hd64465_gpio.o
> +O_OBJS += setup_hd64465.o io_hd64465.o
>  endif

I know that hd64461 is for HP680/690 but can you tell
hd64465 is for which machine .

Thanks .

Best Regards,

Jaswinder.


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one Place.
http://shopping.yahoo.com/

[linuxsh-dev] Re: [linux-sh:01375] trouble with sh-GCC "97" and CVS kernel

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

On Fri, 3 Nov 2000, Rene Malmgren wrote:

> Hi everyone I have been tying to get a kernel working on my Dreamcast
> but unfortunatly so far no luck. I have bean running from troble into
> trouble. But finaly I started to question my GCC. First I used the 2.97
> debian package found at ftp://ftp.m17n.org/super-h/debian. This gcc
> could compile the CVS kernel, but only after I comented out all of the
> FOOBAR and HD64xxxx stuff from the Makefiles. I belive that there are
> some files missing.
> 

There are a couple of files missing for foobar and I just commented them
out of the makefile for now (I believe hd64465_gpio.[co] is one of them).

> Q1: shouldn't it be possible to compile a kernel from CVS with the GCC
> 2.97 from the .deb files?
> 
> the error I got was:
> 
> make[1]: Entering directory `/usr/src/sh/kernel/arch/sh/kernel'
> sh-linux-gcc -D__KERNEL__ -I/usr/src/sh/kernel/include -Wall
> -Wstrict-prototypes
>  -O2 -fomit-frame-pointer -fno-strict-aliasing -ml -m4 -pipe    -c -o
> mach_fooba
> r.o mach_foobar.c
> mach_foobar.c:34: `hd64465_inb' undeclared here (not in a function)
> mach_foobar.c:34: initializer element is not constant
> mach_foobar.c:34: (near initialization for `mv_foobar.mv_inb')
> mach_foobar.c:35: `hd64465_inw' undeclared here (not in a function)
> 
> mach_foobar.c:62: initializer element is not constant
> mach_foobar.c:62: (near initialization for `mv_foobar.mv_irq_demux')
> mach_foobar.c:65: initializer element is not constant
> mach_foobar.c:65: (near initialization for `mv_foobar')
> make[1]: *** [mach_foobar.o] Error 1
> make[1]: Leaving directory `/usr/src/sh/kernel/arch/sh/kernel'
> make: *** [_dir_arch/sh/kernel] Error 2
> 

mach_foobar.c is missing the asm/io_hd64465.h include file.  Add the
#include and it should work.

> 
> the kernel was configured without GDB stub support (kernel-hacker menu)
> and without IDE sufpport. the processortype selected was "GENERIC". To
> me it looks like there is atleast some files missing.
> 
> Now comenting out the "FOOBAR" card (is this a card?) and the hd64461
> witch caused a simelar problem made the kernel compilation come throu.
> Unfortunatly I haven't bean able to get the kernel to boot on my
> Dreamcast and since ther is no FB support installed. I have no way of
> knowing how it fails.
> 
> Q2: Does anyone have a Dreamcast kernel (preferbly in SREC format) that
> I could use to verify my system?
> 

I've gotten it working using GENERIC, but the calibration loop (for
BogoMIPS) and the RTC code doesn't work currently.  I just got some info
on the DC RTC (DC doesn't use the normal sh4 RTC) so I plan on patching
this up this weekend.  I'm also looking on starting the
CONFIG_SH_DREAMCAST stuff, with the mach_vec and I/O, etc.  For now,
comment out calibrate_XXX (I forget the name) in init/main.c and comment
out the RTC stuff in arch/sh/time.c. 

I created a simple "cmdline" file with:
mem=16m console=ttySC1,57600

and that worked as well (serial console).  Also, if you're building for
GENERIC, set the memory start address at 0x8c00f000 so that
.empty_zero_page starts at 0x8c010000 and load the "cmdline" file at
0x8c010100 before loading the kernel.

`make zImage' will work after you change arch/sh/boot/compressed's
Makefile to generate code for elf32-shl *not* elf32-linux or whatever
(just search for it in the file).  With elf32-linux in the linker script,
ld segfaulted (haven't had time to look at this).

> So I tried compiling the GCC. Unfortunatly again I ran into problems. I
> got the GCC from ftp://ftp.m17n.org/super-h/original the file called
> egcs-core-20001002. then I made
> 
> mkdir sh-linux-gnu-gcc
> cd sh-linux-gnu-gcc
> ../egcs-20001002/configure --prefix=/usr/local/sh --target=sh-linux-gnu
> make
> 

...

> 
> Q3: does anybody know what could be the problem? Or perhaps how the gcc
> should be compiled, where you finde the rigt files and so on?
> 

I'm using the latest LinuxSH binutils, gcc-core, and kernel from
SourceForge and everything just about went OK except the problems
mentioned above.  Hopefully this weekend or next week I can post some
examples, ramdisks, etc. with the kernel booting on Dreamcast.

> Tnaks for all your help
> 
> /Rene
> 
> 

M. R.

P.S.: Quick question to maintainers: I just found out and subscribed to
the linuxsh-dev list at SourceForge - is this where I send patches, etc.?

Re: [linuxsh-dev] trouble with sh-GCC "97" and CVS kernel

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

Rene Malmgren wrote:
> 
> Hi everyone I have been tying to get a kernel working on my Dreamcast
> but unfortunatly so far no luck. I have bean running from troble into
> trouble. But finaly I started to question my GCC. First I used the 2.97
> debian package found at ftp://ftp.m17n.org/super-h/debian. This gcc
> could compile the CVS kernel, but only after I comented out all of the
> FOOBAR and HD64xxxx stuff from the Makefiles. I belive that there are
> some files missing.

Dear Rene,

My partner (Greg Banks) and I must apologise to you and the rest of the
team, because we broke the support for the "GENERIC" machine type.
Please apply the attached patch.  Niibe-san, can we check this patch
in please?

Below I would like to review some of your error messages, and attempt
to explain why they are happening, and show you how you can avoid
them.

> the error I got was:
> 
> make[1]: Entering directory `/usr/src/sh/kernel/arch/sh/kernel'
> sh-linux-gcc -D__KERNEL__ -I/usr/src/sh/kernel/include -Wall
> -Wstrict-prototypes
>  -O2 -fomit-frame-pointer -fno-strict-aliasing -ml -m4 -pipe    -c -o
> mach_fooba
> r.o mach_foobar.c
> mach_foobar.c:34: `hd64465_inb' undeclared here (not in a function)

Even though Foobar support has been broken until now, it should not
be necessary to compile mach_foobar.c to get the kernel running on
your DreamCast.  But read on...

> mach_foobar.c:65: initializer element is not constant
> mach_foobar.c:65: (near initialization for `mv_foobar')

Earlier this year, the situation was that once you compiled your
SuperH kernel for a particular machine, it was not possible to use that
kernel on another SuperH machine, even though the processor may be the
same.  Therefore work was done to let us build one kernel which (in
binary form) would run on the widest range of SuperH computers.  This
configuration setting is "GENERIC", and it works by compiling the
particular settings of EVERY board the SuperH supports, and selecting
them at run-time using a mechanism called the "machine vector".

> the kernel was configured without GDB stub support (kernel-hacker menu)
> and without IDE sufpport. the processortype selected was "GENERIC". To

The reason mach_foobar.c is being compiled is because you're compiling
a GENERIC kernel.  So the Foobar configuration must be included.  But
as I said earlier, Foobar (as checked in) is broken at the moment.

Apart from your method, there are two ways of solving this problem.
The first is to apply the attached patch.  The second is to generate
a specific "DreamCast" machine type for the SuperH kernel.  Then
you wouldn't have to specify "GENERIC".  (Actually, this would
be a very useful contribution to our project, if you would consider
doing it).

> So I tried compiling the GCC. Unfortunatly again I ran into problems. I
> got the GCC from ftp://ftp.m17n.org/super-h/original the file called
> egcs-core-20001002. then I made

> Q3: does anybody know what could be the problem? Or perhaps how the gcc
> should be compiled, where you finde the rigt files and so on?

You can ensure the maximum chance of success by following Stuart
Menefy's excellent instructions, posted here:

  http://linuxsh.sourceforge.net/docs/building-source.php3

You can find more information about using CVS here:

  http://sourceforge.net/docman/display_doc.php?docid=763&group_id=1
  http://sourceforge.net/docman/display_doc.php?docid=765&group_id=1

I would suggest you use CVS to get the source for binutils, gdb,
gcc-core and kernel from SourceForge.  Use the four module names I
just gave.  I can verify that the most recent version of these sources
do indeed compile as per Stuart's instructions (except for the
GENERIC/Foobar problem), since I've spent the last few days making
a turnkey script to do the job.

I hope this helps, and I look forward to hearing of your success on the
DreamCast.  (And to your submission of a "DreamCast" machine type!!)

Regards,

Mitch.

[linuxsh-dev] do_gettimeoffset implemented

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

SUGIOKA Toshinobu wrote:
 > do_gettimeoffset() has been implemented.
 > Now, ping prints accurate time like this.

Great!  Please check it in.
-- 

[linuxsh-dev] trouble with sh-GCC "97" and CVS kernel

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

Hi everyone I have been tying to get a kernel working on my Dreamcast
but unfortunatly so far no luck. I have bean running from troble into
trouble. But finaly I started to question my GCC. First I used the 2.97
debian package found at ftp://ftp.m17n.org/super-h/debian. This gcc
could compile the CVS kernel, but only after I comented out all of the
FOOBAR and HD64xxxx stuff from the Makefiles. I belive that there are
some files missing.

Q1: shouldn't it be possible to compile a kernel from CVS with the GCC
2.97 from the .deb files?

the error I got was:

make[1]: Entering directory `/usr/src/sh/kernel/arch/sh/kernel'
sh-linux-gcc -D__KERNEL__ -I/usr/src/sh/kernel/include -Wall
-Wstrict-prototypes
 -O2 -fomit-frame-pointer -fno-strict-aliasing -ml -m4 -pipe    -c -o
mach_fooba
r.o mach_foobar.c
mach_foobar.c:34: `hd64465_inb' undeclared here (not in a function)
mach_foobar.c:34: initializer element is not constant
mach_foobar.c:34: (near initialization for `mv_foobar.mv_inb')
mach_foobar.c:35: `hd64465_inw' undeclared here (not in a function)

.
.
.

mach_foobar.c:62: initializer element is not constant
mach_foobar.c:62: (near initialization for `mv_foobar.mv_irq_demux')
mach_foobar.c:65: initializer element is not constant
mach_foobar.c:65: (near initialization for `mv_foobar')
make[1]: *** [mach_foobar.o] Error 1
make[1]: Leaving directory `/usr/src/sh/kernel/arch/sh/kernel'
make: *** [_dir_arch/sh/kernel] Error 2


the kernel was configured without GDB stub support (kernel-hacker menu)
and without IDE sufpport. the processortype selected was "GENERIC". To
me it looks like there is atleast some files missing.

Now comenting out the "FOOBAR" card (is this a card?) and the hd64461
witch caused a simelar problem made the kernel compilation come throu.
Unfortunatly I haven't bean able to get the kernel to boot on my
Dreamcast and since ther is no FB support installed. I have no way of
knowing how it fails.

Q2: Does anyone have a Dreamcast kernel (preferbly in SREC format) that
I could use to verify my system?

So I tried compiling the GCC. Unfortunatly again I ran into problems. I
got the GCC from ftp://ftp.m17n.org/super-h/original the file called
egcs-core-20001002. then I made

mkdir sh-linux-gnu-gcc
cd sh-linux-gnu-gcc
../egcs-20001002/configure --prefix=/usr/local/sh --target=sh-linux-gnu
make

Unfortunatly I get

.
.
.
make[1]: Entering directory
`/usr/src/sh/gcc-sh-linux-gnu/sh-linux-gnu/zlib'
/bin/sh ./libtool --mode=compile /usr/src/sh/gcc-sh-linux-gnu/gcc/xgcc
-B/usr/src/sh/gcc-sh-linux-gnu/gcc/ -B/usr/local/sh/sh-linux-gnu/bin/
-B/usr/local/sh/sh-linux-gnu/lib/ -isystem
/usr/local/sh/sh-linux-gnu/include -DPACKAGE=\"zlib\"
-DVERSION=\"1.1.3\" -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1  -I.
-I../../../egcs-20001002/zlib      -g -O2 -c
../../../egcs-20001002/zlib/deflate.c
/usr/src/sh/gcc-sh-linux-gnu/gcc/xgcc
-B/usr/src/sh/gcc-sh-linux-gnu/gcc/ -B/usr/local/sh/sh-linux-gnu/bin/
-B/usr/local/sh/sh-linux-gnu/lib/ -isystem
/usr/local/sh/sh-linux-gnu/include -DPACKAGE=\"zlib\"
-DVERSION=\"1.1.3\" -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -I.
-I../../../egcs-20001002/zlib -g -O2 -c
../../../egcs-20001002/zlib/deflate.c  -fPIC -DPIC -o .libs/deflate.o
In file included from ../../../egcs-20001002/zlib/deflate.h:16,
                 from ../../../egcs-20001002/zlib/deflate.c:52:
../../../egcs-20001002/zlib/zutil.h:20:22: string.h: No such file or
directory
../../../egcs-20001002/zlib/zutil.h:21:22: stdlib.h: No such file or
directory
../../../egcs-20001002/zlib/zutil.h:26:22: errno.h: No such file or
directory
make[1]: *** [deflate.lo] Error 1
make[1]: Leaving directory
`/usr/src/sh/gcc-sh-linux-gnu/sh-linux-gnu/zlib'
make: *** [all-target-zlib] Error 2

Q3: does anybody know what could be the problem? Or perhaps how the gcc
should be compiled, where you finde the rigt files and so on?


Tnaks for all your help

/Rene

[linuxsh-dev] do_gettimeoffset implemented

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

Hi, All.

do_gettimeoffset() has been implemented.
Now, ping prints accurate time like this.

PING sourceforge.net (216.104.232.234): 56 data bytes
64 bytes from 216.104.232.234: icmp_seq=0 ttl=238 time=166.5 ms
64 bytes from 216.104.232.234: icmp_seq=1 ttl=238 time=155.5 ms
64 bytes from 216.104.232.234: icmp_seq=2 ttl=238 time=153.9 ms
64 bytes from 216.104.232.234: icmp_seq=3 ttl=238 time=153.0 ms

Regards.

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.111
diff -u -r1.111 ChangeLog
--- ChangeLog	2000/11/03 12:30:47	1.111
+++ ChangeLog	2000/11/03 16:23:04
@@ -1,3 +1,10 @@
+2000-11-04  SUGIOKA Toshinobu  <su...@it...>
+
+	* arch/sh/kernel/time.c (do_gettimeoffset): Implemented.
+	(time_init): TMU0 counter value changed.
+
+	* include/asm-sh/timex.h (CLOCK_TICK_RATE) Changed.
+
 2000-11-03  SUGIOKA Toshinobu  <su...@it...>
 
 	* arch/sh/kernel/irq_ipr.c Add PINT interrupt hanlers.
Index: arch/sh/kernel/time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.17
diff -u -r1.17 time.c
--- arch/sh/kernel/time.c	2000/10/27 01:14:20	1.17
+++ arch/sh/kernel/time.c	2000/11/03 16:23:05
@@ -118,13 +118,62 @@
 extern unsigned long wall_jiffies;
 #define TICK_SIZE tick
 
+static unsigned long do_gettimeoffset(void)
+{
+	int count;
+
+	static int count_p = 0x7fffffff;    /* for the first call after boot */
+	static unsigned long jiffies_p = 0;
+
+	/*
+	 * cache volatile jiffies temporarily; we have IRQs turned off. 
+	 */
+	unsigned long jiffies_t;
+
+	/* timer count may underflow right here */
+	count = ctrl_inl(TMU0_TCNT);	/* read the latched count */
+
+ 	jiffies_t = jiffies;
+
+	/*
+	 * avoiding timer inconsistencies (they are rare, but they happen)...
+	 * there is one kind of problem that must be avoided here:
+	 *  1. the timer counter underflows
+	 */
+
+	if( jiffies_t == jiffies_p ) {
+		if( count > count_p ) {
+			/* the nutcase */
+
+			if(ctrl_inw(TMU0_TCR) & 0x100) { /* Check UNF bit */
+				/*
+				 * We cannot detect lost timer interrupts ... 
+				 * well, that's why we call them lost, don't we? :)
+				 * [hmm, on the Pentium and Alpha we can ... sort of]
+				 */
+				count -= LATCH;
+			} else {
+				printk("do_slow_gettimeoffset(): hardware timer problem?\n");
+			}
+		}
+	} else
+		jiffies_p = jiffies_t;
+
+	count_p = count;
+
+	count = ((LATCH-1) - count) * TICK_SIZE;
+	count = (count + LATCH/2) / LATCH;
+
+	return count;
+}
+
 void do_gettimeofday(struct timeval *tv)
 {
 	unsigned long flags;
 	unsigned long usec, sec;
 
 	read_lock_irqsave(&xtime_lock, flags);
-	usec = 0;
+	usec = do_gettimeoffset();
 	{
 		unsigned long lost = jiffies - wall_jiffies;
 		if (lost)
@@ -143,11 +192,6 @@
 	tv->tv_usec = usec;
 }
 
-/*
- * Could someone please implement this...
- */
-#define do_gettimeoffset() 0
-
 void do_settimeofday(struct timeval *tv)
 {
 	write_lock_irq(&xtime_lock);
@@ -440,7 +488,7 @@
 	module_clock = master_clock/pfc;
 	printk("Module clock: %d.%02dMHz\n",
 	       (module_clock/1000000), (module_clock % 1000000)/10000);
-	interval = (module_clock/(HZ*4));
+	interval = (module_clock/4 + HZ/2) / HZ;
 
 	printk("Interval = %ld\n", interval);
 
Index: include/asm-sh/timex.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/timex.h,v
retrieving revision 1.2
diff -u -r1.2 timex.h
--- include/asm-sh/timex.h	2000/07/11 01:02:39	1.2
+++ include/asm-sh/timex.h	2000/11/03 16:23:05
@@ -6,7 +6,7 @@
 #ifndef __ASM_SH_TIMEX_H
 #define __ASM_SH_TIMEX_H
 
-#define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+#define CLOCK_TICK_RATE	(current_cpu_data.module_clock/4) /* Underlying HZ */
 #define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
 #define FINETUNE ((((((long)LATCH * HZ - CLOCK_TICK_RATE) << SHIFT_HZ) * \
 	(1000000/CLOCK_TICK_FACTOR) / (CLOCK_TICK_RATE/CLOCK_TICK_FACTOR)) \


-----
SUGIOKA Toshinobu

[linuxsh-dev] Re: [linux-sh:01328] Re: a patch for kernel/time.c

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

>>>>> "M" == M R Brown <ma...@uw...> writes:

M> On 24 Oct 2000, Jesper Skov wrote:
>> Btw, I know that David Woodhouse fixed something in the clock
>> calibration code for SH. I'll try to get around to fishing out that
>> patch some time this week and submit it for inclusion in the
>> Linux/SH kernel.
>> 

M> Do you have this patch available?  I'm trying to figure out what's
M> going on with the Dreamcast, because calibration, etc. doesn't work
M> here either.

I posted it last week on linuxsh-dev.

Jesper

[linuxsh-dev] PINT interrupt handler

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

SUGIOKA Toshinobu wrote:
 > I have implemented PINT interrupt handler for SH7707/SH7709.
 > Assigned irq numbers are 80-95(SH7709), 64-79(SH7707). is this OK?
 > I tested this on my SH7709A board, and it works fine.

OK.  Please check it in.

I think that pending issues are Peter's patch for CallistoPro and
Takeshi's HP related patch.  Let's merge them.
-- 

[linuxsh-dev] Re: [linux-sh:01328] Re: a patch for kernel/time.c

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

On 24 Oct 2000, Jesper Skov wrote:

> Btw, I know that David Woodhouse fixed something in the clock
> calibration code for SH. I'll try to get around to fishing out that
> patch some time this week and submit it for inclusion in the Linux/SH
> kernel.
> 

Do you have this patch available?  I'm trying to figure out what's going
on with the Dreamcast, because calibration, etc. doesn't work here either. 

> Jesper
> 
> 

M. R.

[linuxsh-dev] PINT interrupt handler

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

Hi all,

I have implemented PINT interrupt handler for SH7707/SH7709.
Assigned irq numbers are 80-95(SH7709), 64-79(SH7707). is this OK?
I tested this on my SH7709A board, and it works fine.

Regards.

--- kernel/ChangeLog	Thu Nov  2 23:00:35 2000
+++ modified/ChangeLog	Fri Nov  3 00:57:15 2000
@@ -1,3 +1,21 @@
+2000-11-03  SUGIOKA Toshinobu  <su...@it...>
+
+	* arch/sh/kernel/irq_ipr.c Add PINT interrupt hanlers.
+	(ipr_irq_demux): IPR/PINT interrupt demux added.
+	(pint_irq_type, pint_map): Added.
+	(init_IRQ): Add PINT initializer.
+	(*_IPR_*): Fixed typo.
+
+	* arch/sh/kernel/setup_hd64461.c (hd64461_irq_demux): use __irq_demux
+
+	* include/asm-sh/irq.h (NR_IRQS): changed.
+	(irq_demux): Changed.
+	(__irq_demux): Defined.
+	(PINT_IRQ_BASE, PINT0_IRQ, PINT8_IRQ, PINT0_IPR_ADDR, PINT8_IPR_ADDR,
+	PINT0_IPR_POS, PINT8_IPR_POS, PINT0_PRIORITY, PINT8_PRIORITY): added.
+	(PORT_PADR, PORT_PBDR, PORT_PCDR, PORT_PFDR): added.
+	(*_IPR_*): Fixed typo.
+
 2000-11-02  Takashi Yoshii  <yos...@hi...>
 
 	* arch/sh/kernel/dma.c: New file.

Re: [linuxsh-dev] Networking with SH3

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

At 16:04 00/11/02 +0100, you wrote:
>which I don't know. SH3 on my board is conected with Fast-Ethernet
>Controller LAN 91C100 FD from SMSC. I wonder if I have to write a driver
>from scratch or I will use an example code or perhaps it was already made.

smc9194.c should be used for 91C100. see drivers/net/smc9194.[ch]

Regards.

----
SUGIOKA Toshinobu

[linuxsh-dev] Networking with SH3

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

Hello everybody,

Could someone explain me the current status of the problem: networking with
SH3? I have seen a couple of emails about this topic but on some platforms,
which I don't know. SH3 on my board is conected with Fast-Ethernet
Controller LAN 91C100 FD from SMSC. I wonder if I have to write a driver
from scratch or I will use an example code or perhaps it was already made.
I'm grateful for every tip,

best regards 
Pawel