linuxsh-dev

Re: [linuxdc-dev] Re: [linuxsh-dev] Completion of LinuxDC merge into LinuxSH

[M. R. B. <mr...@0x...>]

* Peter De Schrijver <p2...@mi...> on Thu, May 24, 2001:

> 
> Last weekend I tried the cvs snapshot of the DC Linux kernel on a dreamcast
> with BBA. I downloaded the kernel via the serial port. I had to make some 
> small changes to the pci_gaps code to get the BBA to work.
> 

Yeah, I had those problems before, but Yaegashi's BBA code doesn't exhibit
that bug (uploading over serial won't init the BBA).  I still need to merge
what I did last nite back into LinuxDC, so for the next couple of hours
LinuxSH contains the most recent kernel :).  I've tested the BBA with both
BBA upload and serial upload, and it appears to work fine.

> > - Finish rewriting Maple subsystem
> > - Finish drivers for the vmu MTD flash and LCD fb
> > - Finish AICA RTC stuff
> > - GD-ROM support
> > - MTD driver for DC's internal flash
> 
> Any pointers on this ? I have done some work on MTD drivers.
> 

Paul Mundt (Lethal) and myself (mrbrown) hang out in #linuxdc on
irc.openprojects.net.  This is where we do the majority of discussion on
the Maple stuff.  Once I do the (LinuxDC) merge, we'll probably start
committing things to LinuxDC CVS, and you're welcome to stop by to get a
bead on where things are going.

The internal flash interface requires more info than what I have currently,
and Marcus Comstedt seems to know the most about its specifics.

> 
> I was planning on looking into this RSN. I have experience with ARM programming
> on both linux and eCos. I was thinking of running eCos on the AICA :)
> 

Wow, I've actually been trying to stay away from the ARM as much as
possible :).  As soon as you have a patch (even your pci_gaps fix from
above would be fine), send me it with your SF info and I'll add you to the
list of developers :).

M. R.

Re: [linuxdc-dev] Re: [linuxsh-dev] Completion of LinuxDC merge into LinuxSH

[<p2...@mi...>]

Hi,

> * YAEGASHI Takeshi <t...@ke...> on Thu, May 24, 2001:
> 
> > 
> > This surprised me a bit, because I've paied little attention to
> > your project's status for a long time.  Now it seems much better
> > than my drivers. ;-> Great work.
> > 
> 
> Hehe, imagine my surprise when your code was finally released, and we had
> basically the same drivers!  All of your work is appreciated, and I understand
> the situation you were in before, and I'm glad you're able to hack on these
> drivers :).  Here's what's on LinuxDC's agenda in the next few weeks, for
> those of you out there who want to help out:
> 

Last weekend I tried the cvs snapshot of the DC Linux kernel on a dreamcast
with BBA. I downloaded the kernel via the serial port. I had to make some 
small changes to the pci_gaps code to get the BBA to work.

> - Finish rewriting Maple subsystem
> - Finish drivers for the vmu MTD flash and LCD fb
> - Finish AICA RTC stuff
> - GD-ROM support
> - MTD driver for DC's internal flash

Any pointers on this ? I have done some work on MTD drivers.

> - ALSA or OSS drivers for the AICA system

I was planning on looking into this RSN. I have experience with ARM programming
on both linux and eCos. I was thinking of running eCos on the AICA :)

Peter.

Re: [linuxdc-dev] Re: [linuxsh-dev] Completion of LinuxDC merge into LinuxSH

[M. R. B. <mr...@li...>]

* YAEGASHI Takeshi <t...@ke...> on Thu, May 24, 2001:

> 
> This surprised me a bit, because I've paied little attention to
> your project's status for a long time.  Now it seems much better
> than my drivers. ;-> Great work.
> 

Hehe, imagine my surprise when your code was finally released, and we had
basically the same drivers!  All of your work is appreciated, and I understand
the situation you were in before, and I'm glad you're able to hack on these
drivers :).  Here's what's on LinuxDC's agenda in the next few weeks, for
those of you out there who want to help out:

- Finish rewriting Maple subsystem
- Finish drivers for the vmu MTD flash and LCD fb
- Finish AICA RTC stuff
- GD-ROM support
- MTD driver for DC's internal flash
- ALSA or OSS drivers for the AICA system
- if necessary, External DMA, and other minor subsystems

> 
> You may know BERO has already had the GD-ROM driver ported from
> NetBSD:
> 
> 	http://www.geocities.co.jp/Playtown/2004/dcdev/linux/linux.html
> 
> I have another driver based on this, and a standalone Debian
> system can boot on my Dreamcast with the kernel powered by it.
> 

Wow! This is ... cool! :)  I'm glad we have a starting point for writing a
GD-ROM driver, would you mind sending me the driver you have as well?  Some
of the things I wanted to support in addition to the PIO stuff Marcus has
done are DMA reads and audio playing, which is why I've been hesitant just
using his "stock" GD-ROM code :).  This is a tremendous help, thanks!

> I'm now working on adding GD-ROM drive and ISO9660 supports to
> eCos+RedBoot/Dreamcast to make it serve as a bootloader, and
> planning to distribute CD-Rs at LinuxWorld Expo/Tokyo.
> 

That would also be great, we've been mostly using dcload for sending
kernels over the BBA, but once we get proper GD-ROM support added a decent
bootloader will be required.  I've played with RedBoot a little bit, but
haven't sat down to get kernels booting via TFTP, etc.  I would be
interested in helping you out with this, just let me know :).

For those of you out there who don't hack kernels but still want to help,
you can, by:

- testing the kernels, finding bugs, and reporting them
- helping with documentation where needed (it's needed *badly*, ATM)
- using the cross-tools to port your favorite app/library over (hehe, I've
  already done SDL, just need to accel. that damn frame buffer :)
- helping get binary images together for those who don't have the means to
  build everything from scratch
- doing whatever else you can think of :)

M. R.

Re: [linuxsh-dev] Completion of LinuxDC merge into LinuxSH

[YAEGASHI T. <t...@ke...>]

In the article <200...@ma...>,
"M. R. Brown" <mr...@li...> wrote:

> Hi all,
> 
> Sorry for it taking so long, but I've completed the merge of LinuxDC driver
> support into LinuxSH:
> 
> - The Maple Bus driver has been shuffled around a bit to:
>   a) make it more consistent with kernel driver placement (Maple is a
>      *subsystem*, not a single driver ;-),
>   b) facilitate it's (complete) rewrite by Paul Mundt and myself.  The new
>      Maple core will be able to support a wide range of DC peripherals,
>      including MTD storage and framebuffer support for VMUs.
> - Support for Dreamcast System ASIC hardware events.  This allows us to
>   map hardware events to virtual IRQs, so that drivers can respond to
>   events as they would a normal IRQ.  Examples of this include the vsync
>   interrupt for the framebuffer, the BBA IRQ, GD-ROM DMA/Command
>   completion, etc.
> - The generic dcfb framebuffer driver has been replaced with the pvr2
>   framebuffer, in hopes of providing a standard driver for all video cards
>   based on the PowerVR2 architecture.  Acceleration (DMA blitting, etc.)
>   and better video mode support are on its way for pvr2.
> 
> There is some RTC stuff that's currently missing, but that's being rewritten
> so that I can integrate it with the new RTC changes.
> 
> Now that the basic stuff's been merged, future DC driver development will
> be folded back into LinuxSH after testing, so you'll always be able to grab
> the latest development stuff from linuxdc.org.

This surprised me a bit, because I've paied little attention to
your project's status for a long time.  Now it seems much better
than my drivers. ;-> Great work.

Please go ahead with merging your works into LinuxSH's CVS.


> I'm currently finishing up gathering enough info to write a GD-ROM driver,
> hopefully I'll be able to begin work on it this weekend.

You may know BERO has already had the GD-ROM driver ported from
NetBSD:

	http://www.geocities.co.jp/Playtown/2004/dcdev/linux/linux.html

I have another driver based on this, and a standalone Debian
system can boot on my Dreamcast with the kernel powered by it.

I'm now working on adding GD-ROM drive and ISO9660 supports to
eCos+RedBoot/Dreamcast to make it serve as a bootloader, and
planning to distribute CD-Rs at LinuxWorld Expo/Tokyo.

--
YAEGASHI Takeshi <t...@ke...>

[linuxsh-dev] Completion of LinuxDC merge into LinuxSH

[M. R. B. <mr...@li...>]

Hi all,

Sorry for it taking so long, but I've completed the merge of LinuxDC driver
support into LinuxSH:

- The Maple Bus driver has been shuffled around a bit to:
  a) make it more consistent with kernel driver placement (Maple is a
     *subsystem*, not a single driver ;-),
  b) facilitate it's (complete) rewrite by Paul Mundt and myself.  The new
     Maple core will be able to support a wide range of DC peripherals,
     including MTD storage and framebuffer support for VMUs.
- Support for Dreamcast System ASIC hardware events.  This allows us to
  map hardware events to virtual IRQs, so that drivers can respond to
  events as they would a normal IRQ.  Examples of this include the vsync
  interrupt for the framebuffer, the BBA IRQ, GD-ROM DMA/Command
  completion, etc.
- The generic dcfb framebuffer driver has been replaced with the pvr2
  framebuffer, in hopes of providing a standard driver for all video cards
  based on the PowerVR2 architecture.  Acceleration (DMA blitting, etc.)
  and better video mode support are on its way for pvr2.

There is some RTC stuff that's currently missing, but that's being rewritten
so that I can integrate it with the new RTC changes.

Now that the basic stuff's been merged, future DC driver development will
be folded back into LinuxSH after testing, so you'll always be able to grab
the latest development stuff from linuxdc.org.

I'm currently finishing up gathering enough info to write a GD-ROM driver,
hopefully I'll be able to begin work on it this weekend.

Have fun!

M. R.

[linuxsh-dev] A problem of SH PIC ABI

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

Hi,

I'd like to report a problem of SH PIC ABI and changes of toolchain
needed for it.

Gcc usually uses r2 to pass the address of the returned structure when
the structure valued function is called. On the other hand, current SH
PLT code uses r0, r1 and r2. So such function never work in the shared
library. This problem was reported by Yaegashi-san when he ported debian
apt package.

I've written new PLT codes which use r0 and r1 only. This needs a tiny
change of the dynamic linker so to handle both old and new PLT codes.
With this change, we can use the old and new binaries at the same time.
This proposal was sent to the binutils mailing list and is approved.
Of course, it's an additional change of SH PIC ABI. I've talked with
Alexandre Oliva in Red Hat about this issue and he and I contacted with
Hitachi America and Japan guys who are responsible for this change. They
also approved it.
I've posted a patch for the dynamic linker to the libc mailing list and
it's approved now.
So, when you try to update the binutils from the sources in mainline cvs
and the SH local patch, please don't forget to update your libc too. If
you use your own dynamic linker, you have to fix it slightly.

Regards,
	kaz

[linuxsh-dev] Re: unknown register

[Jaswinder S. <jas...@3d...>]

I am sorry , it was my fault.

Thanks ,

Jaswinder.

  ----- Original Message -----=20
  From: Jaswinder Singh=20
  To: lin...@m1... ; lin...@li...=20
  Cc: Jaswinder Singh=20
  Sent: Wednesday, May 23, 2001 10:50 AM
  Subject: unknown register


  Hi,

  I am getting this warning :-

  /home/jsr/linux/include/asm/bitops.h:117: unknown register name `t' in =
`asm'

  how to overcome this waring.=20

  this will make some effect in kernel or not ?

  /* part of /home/jsr/linux/include/asm/bitops.h*/
  static __inline__ unsigned long ffz(unsigned long word)
  {
   unsigned long result;

   __asm__("1:\n\t"
    "shlr %1\n\t"
    "bt/s 1b\n\t"
    " add #1, %0"
    : "=3Dr" (result), "=3Dr" (word)
    : "0" (~0L), "1" (word)
    : "t");                                        <---------=20
   return result;
  }

  Thanks you,

  Best Regards,

  Jaswinder.
  --=20
  These are my opinions not 3Di.

[linuxsh-dev] unknown register

[Jaswinder S. <jas...@3d...>]

Hi,

I am getting this warning :-

/home/jsr/linux/include/asm/bitops.h:117: unknown register name `t' in =
`asm'

how to overcome this waring.=20

this will make some effect in kernel or not ?

/* part of /home/jsr/linux/include/asm/bitops.h*/
static __inline__ unsigned long ffz(unsigned long word)
{
 unsigned long result;

 __asm__("1:\n\t"
  "shlr %1\n\t"
  "bt/s 1b\n\t"
  " add #1, %0"
  : "=3Dr" (result), "=3Dr" (word)
  : "0" (~0L), "1" (word)
  : "t");                                        <---------=20
 return result;
}

Thanks you,

Best Regards,

Jaswinder.
--=20
These are my opinions not 3Di.

Re: [linuxsh-dev] PCI for the SH7751 Solution Engine

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

Oops... I was so focused on the fix below I forgot to include
an even more important one... a misplaced bracket in io_se.c
(outside an ifdef when it should be in) prevents compilation
for the 7709/7750 Solution Engine.  The attached patch will
fix it (and also moves new variables inside the ifdef, so the
warnings about unused variables are reduced.)

NIIBE Yutaka wrote:

> Jeremy Siegel wrote:
>  > We found a negative side-effect in our patch; the change in
>  > include/asm-sh/machvec.h mistakenly causes MACH_SE to
>  > be turned off for the older Solution Engine configurations. It
>  > seems that only the CF Enabler and STNIC support look at
>  > that (everything else should work fine). Maybe we should
>  > make it a separate machine type sometime in the future, but
>  > for the moment I think the following patch takes care of it:
>
> Thanks a lot.

[linuxsh-dev] Booting problems with 2.4.4

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

I'm having some trouble with the 2.4.4 kernel that didn't exist under
previous kernel versions.  When the kernel begins executing user space
commands, immediately after mounting the initial ramdisk, I get stuck in an
infinite loop of data address exceptions (exception code 0xE0).  At first I
thought it may be devfs or or something similar, but those options have been
disabled and the same problem occurs.  Likewise I rebuilt all the user space
stuff with the 2.4.4 kernel headers.  I've tried both the Big Sur port and
just the "Bare CPU" target with essentially nothing in the kernel.  Has
anyone else been experiencing similar problems with 2.4.4 or know what the
problem may be?

Dustin.

Here is a transcript of the boot messages....
***********************************************************************
....
block: queued sectors max/low 34682kB/11560kB, 128 slots per queue
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 10240k freed
SuperH SCI(F) driver initialized
ttySC0 at 0xffe00000 is a SCI
ttySC1 at 0xffe80000 is a SCIF
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 28k freed
INIT:
***********************************************************************
It is dead now...

Re: [linuxsh-dev] PCI for the SH7751 Solution Engine

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

NIIBE Yutaka wrote:

> Looking the specification of SolutionEngine 7751, I'd prefer having
> separate machine vector or I/O routines for that.  It looks for me
> that there's almost no common parts between SolutionEngine
> 7709A/7750/7750S and 7751.  Well, the name is common, I know... ;-)
>
> Opinions?

Yeah, other than the name it's a different beast... I'll talk to my
colleague Ian (who knows a lot more about PCI than me!) when
he gets back in town; next patch we send up for that we'll look
at changing it [unless there's lots of objections on the list!]

--Jeremy Siegel

[linuxsh-dev] new build procedure and patches

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

Hi all,

I've uploaded new procedure and patches for building kernel and
toolchain.

<ftp://ftp.aandd.co.jp/pub/linuxsh/20010515-gcc2.97/>

This time,
-official 2.4.4 Kernel
-Sugioka-san's RTC enhancement to the kernel
-Kojima-san's pthread mutex fix in glibc
are incorporated. Appreciations should go to Sugioka-san and Kojima-san.

binutils and gcc are not changed from previous set.

As before, those don't contain recent changes made to the CVS kernel.

Any comments or suggestions will be much appreciated.

This is not "APPROVED" by anybody nor "DEFINITIVE", as before.
Use at your own lisk.

+-------------------------------------+
| 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:01658] Re: SH3 reference design examples.

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

On May 15,  3:26am, gb...@po... wrote:
> Subject: [linux-sh:01658] Re: SH3 reference design examples.
> 
> Gray, Tim wrote:
> > 
> > Finally, does the linux port for the SH have drivers to interface to the
> > HD64465's I/O?
> 
> Going through the headings in the manual...
> (disclaimer: I haven't actually looked at kernel code for
> some weeks).
> 
> PCMCIA - yes
> AFE - no
> GPIO - yes
> Interrupt controller - yes
> Power management - no
> Timer - not generically
> Keyboard Controller - no
> UART - yes
> Parallel port - no
> PS/2 interface - I have some code which I can't test
>                  and can't release.  Sigh.

I've put together a driver for this which I was planning to release in the
next few days. 

> Audio CODEC - no
> IrDA - no
> USB - I have a partial implementation but can't do any more
>       work on it.  I believe somebody in Stuart Menefy's group
>       is also working on it.

I'm afraid not. We had a look at it and decided that it was going to be
too big a change to the existing drivers.

> ADC - not generically
> 
> I have platform-specific code which uses GPIO, Timer and
> ADC to drive a touch panel interface, so I know those can
> be made to work.
> 
> 
> Greg.
> -- 
> These are my opinions not PPIs.
>-- End of excerpt from gb...@po...

[linuxsh-dev] Re: [linux-sh:01657] SH3 reference design examples.

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

Gray, Tim wrote:
> 
> Finally, does the linux port for the SH have drivers to interface to the
> HD64465's I/O?

Going through the headings in the manual...
(disclaimer: I haven't actually looked at kernel code for
some weeks).

PCMCIA - yes
AFE - no
GPIO - yes
Interrupt controller - yes
Power management - no
Timer - not generically
Keyboard Controller - no
UART - yes
Parallel port - no
PS/2 interface - I have some code which I can't test
                 and can't release.  Sigh.
Audio CODEC - no
IrDA - no
USB - I have a partial implementation but can't do any more
      work on it.  I believe somebody in Stuart Menefy's group
      is also working on it.
ADC - not generically

I have platform-specific code which uses GPIO, Timer and
ADC to drive a touch panel interface, so I know those can
be made to work.


Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] SH3 reference design examples.

[Gray, T. <Gra...@br...>]

I was wondering if there are any reference designs out there (with
schematics) available that use the SH7709 with the HD64465 Companion IO
chip.

There was nothing available on the Hitachi website as a schematic (only
abstracts and conceptual texts).

I have looked throughout the archives for the list and poured over the
DAHLIA schematics and have decided that using the SH7709 (and/or it's
cousins) would work for my project.

Finally, does the linux port for the SH have drivers to interface to the
HD64465's I/O?

Thanks.


Tim 

Re: [linuxsh-dev] PCI for the SH7751 Solution Engine

[Jaswinder S. <jas...@3d...>]

Dear Niibe san,

>
> Looking the specification of SolutionEngine 7751, I'd prefer having
> separate machine vector or I/O routines for that.  It looks for me
> that there's almost no common parts between SolutionEngine
> 7709A/7750/7750S and 7751.  Well, the name is common, I know... ;-)
>
> Opinions?
> --

I think that there is no need to change machine vector or I/O routines for
7751 . if you do not handle PCI in 7751 it is almost same as 7750. PCIC is
additional feature in 7751 but basics are same.

I am not happy with new io_se.c , i think there is no need to change in
io_se.c for PCIC , please refer to the I/O routines of intel architecture is
any thing metioned in it regarding PCI ? all this should be in PCI files .

Please refer to the files regarding PCI , which i send you and Kojima-san
last year .

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.

Re: [linuxsh-dev] PCI for the SH7751 Solution Engine

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

Jeremy Siegel wrote:
 > We found a negative side-effect in our patch; the change in
 > include/asm-sh/machvec.h mistakenly causes MACH_SE to
 > be turned off for the older Solution Engine configurations. It
 > seems that only the CF Enabler and STNIC support look at
 > that (everything else should work fine). Maybe we should
 > make it a separate machine type sometime in the future, but
 > for the moment I think the following patch takes care of it:

Thanks a lot.

Looking the specification of SolutionEngine 7751, I'd prefer having
separate machine vector or I/O routines for that.  It looks for me
that there's almost no common parts between SolutionEngine
7709A/7750/7750S and 7751.  Well, the name is common, I know... ;-)

Opinions?
-- 

Re: [linuxsh-dev] Re: [linux-sh:01651] unresolved symbol __udivsi3_i4

[Jaswinder S. <jas...@3d...>]

Dear Mitch,

> >
> > Thank you very much for your help and reply.
>
> Don't thank me unless it helped :-)  Did it?
>

I am sorry , i am getting some hardware problem in my SH4 board regarding
flash memory . I am bringing some other boards and i will let you know as
soon as i am able to test on it.

Thank you,

Best Regards,

Jaswinder.
--
These are my opinions not 3Di.

Re: [linuxsh-dev] Re: [linux-sh:01651] unresolved symbol __udivsi3_i4

[Mitch D. <mj...@al...>]

Jaswinder Singh wrote:
> 
> Dear Mitch,
> 
> Thank you very much for your help and reply.

Don't thank me unless it helped :-)  Did it?

Regards,

Mitch.
-- 
mailto:mj...@al...
mailto:md...@po...

Re: [linuxsh-dev] Re: [linux-sh:01651] unresolved symbol __udivsi3_i4

[Mitch D. <mj...@al...>]

Jaswinder Singh wrote:
> 
> hello all,
> 
> I am getting almost same error as mentioned in (by yaegashi-san):-
> 
> http://www.m17n.org/linux-sh/ml/linux-sh-ja/2000-09/msg00002.html
> 
> and kojima-san gave the reply for it :-
> 
> http://www.m17n.org/linux-sh/ml/linux-sh-ja/2000-09/msg00003.html
> 
> Can somebody translate the reply from Kojima-san in English .

I cannot, but you might like to try something like
this patch:

diff -X /usr/local/lib/dontdiff -x #*# -x *~ -x vmlinux.lds -u -r --new-file ker
--- kernel-pre-ppi-3/arch/sh/kernel/sh_ksyms.c  2001/01/02 16:54:19
+++ kernel/drivers/arch/sh/kernel/sh_ksyms.c    2001/01/08 13:56:49
@@ -66,6 +78,8 @@
 /* These symbols are generated by the compiler itself */
 #ifdef __SH4__

+DECLARE_EXPORT(__udivsi3);
+DECLARE_EXPORT(__sdivsi3);
 DECLARE_EXPORT(__movstr_i4_even);
 DECLARE_EXPORT(__movstr_i4_odd);
 DECLARE_EXPORT(__ashrdi3);

sh_ksyms.c controls which symbols are exported.
If a symbol is not exported, insmodding something
which uses that symbol will fail.

You'll need to tweak the symbols to match what you want.

Regards,

Mitch.
-- 
mailto:mj...@al...
mailto:md...@po...

Re: [linuxsh-dev] Re: [linux-sh:01651] unresolved symbol __udivsi3_i4

[Jaswinder S. <jas...@3d...>]

Dear Mitch,

Thank you very much for your help and reply.

Best Regards,

Jaswinder.

----- Original Message -----
From: "Mitch Davis" <mj...@al...>
To: "Jaswinder Singh" <jas...@3d...>
Cc: <lin...@m1...>; <lin...@li...>
Sent: Saturday, May 12, 2001 4:58 AM
Subject: Re: [linuxsh-dev] Re: [linux-sh:01651] unresolved symbol
__udivsi3_i4


> Jaswinder Singh wrote:
> >
> > hello all,
> >
> > I am getting almost same error as mentioned in (by yaegashi-san):-
> >
> > http://www.m17n.org/linux-sh/ml/linux-sh-ja/2000-09/msg00002.html
> >
> > and kojima-san gave the reply for it :-
> >
> > http://www.m17n.org/linux-sh/ml/linux-sh-ja/2000-09/msg00003.html
> >
> > Can somebody translate the reply from Kojima-san in English .
>
> I cannot, but you might like to try something like
> this patch:
>
> diff -X /usr/local/lib/dontdiff -x #*# -x *~ -x
vmlinux.lds -u -r --new-file ker
> --- kernel-pre-ppi-3/arch/sh/kernel/sh_ksyms.c  2001/01/02 16:54:19
> +++ kernel/drivers/arch/sh/kernel/sh_ksyms.c    2001/01/08 13:56:49
> @@ -66,6 +78,8 @@
>  /* These symbols are generated by the compiler itself */
>  #ifdef __SH4__
>
> +DECLARE_EXPORT(__udivsi3);
> +DECLARE_EXPORT(__sdivsi3);
>  DECLARE_EXPORT(__movstr_i4_even);
>  DECLARE_EXPORT(__movstr_i4_odd);
>  DECLARE_EXPORT(__ashrdi3);
>
> sh_ksyms.c controls which symbols are exported.
> If a symbol is not exported, insmodding something
> which uses that symbol will fail.
>
> You'll need to tweak the symbols to match what you want.
>
> Regards,
>
> Mitch.
> --
> mailto:mj...@al...
> mailto:md...@po...
>

[linuxsh-dev] Re: [linux-sh:01651] unresolved symbol __udivsi3_i4

[Jaswinder S. <jas...@3d...>]

hello all,

I am getting almost same error as mentioned in (by yaegashi-san):-

http://www.m17n.org/linux-sh/ml/linux-sh-ja/2000-09/msg00002.html

and kojima-san gave the reply for it :-

http://www.m17n.org/linux-sh/ml/linux-sh-ja/2000-09/msg00003.html

Can somebody translate the reply from Kojima-san in English .

Thank you,

Best Regards,

Jaswinder.

----- Original Message -----
From: "Jaswinder Singh" <jas...@3d...>
To: <kk...@rr...>; <lin...@m1...>;
<lin...@li...>
Cc: "Jaswinder Singh" <jas...@3d...>
Sent: Friday, May 11, 2001 9:04 PM
Subject: [linux-sh:01651] unresolved symbol __udivsi3_i4


> Dear Kojima-san and others ,
>
> I am getting an error : unresolved symbol __udivsi3_i4 .
>
> How to overcome this problem.
>
> Thank you ,
>
> Best Regards,
>
> Jaswinder.
> --
> These are my opinions not 3Di.
>
>

[linuxsh-dev] unresolved symbol __udivsi3_i4

[Jaswinder S. <jas...@3d...>]

Dear Kojima-san and others ,

I am getting an error : unresolved symbol __udivsi3_i4 .

How to overcome this problem.

Thank you ,

Best Regards,

Jaswinder.
-- 
These are my opinions not 3Di.

Re: [linuxsh-dev] PCI for the SH7751 Solution Engine

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

NIIBE Yutaka wrote:

> Except irq.c change, the patches are incorporated.
> --
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev

We found a negative side-effect in our patch; the change in
include/asm-sh/machvec.h mistakenly causes MACH_SE to
be turned off for the older Solution Engine configurations. It
seems that only the CF Enabler and STNIC support look at
that (everything else should work fine). Maybe we should
make it a separate machine type sometime in the future, but
for the moment I think the following patch takes care of it:

diff -Nu machvec.h{.bak,}
--- machvec.h.bak Fri May 11 16:39:32 2001
+++ machvec.h Fri May 11 16:41:07 2001
@@ -91,15 +91,11 @@
 #define MACH_DREAMCAST (sh_mv.mv_hw_dreamcast)
 #define MACH_BIGSUR  (sh_mv.mv_hw_bigsur)
 #else
-# ifdef CONFIG_SH_SOLUTION_ENGINE
+# if defined(CONFIG_SH_SOLUTION_ENGINE) || \
+     defined(CONFIG_SH_7751_SOLUTION_ENGINE)
 #  define MACH_SE  1
 # else
 #  define MACH_SE  0
-# endif
-# ifdef CONFIG_SH_7751_SOLUTION_ENGINE
-#  define MACH_SE               1
-# else
-#  define MACH_SE               0
 # endif
 # ifdef CONFIG_SH_HP600
 #  define MACH_HP600  1

Would you be able to check that in so pulling CVS source?

Thanks!
  --Jeremy Siegel

[linuxsh-dev] PCI for the SH7751 Solution Engine

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

Except irq.c change, the patches are incorporated.
--