linuxsh-dev

[linuxsh-dev] Who's currently maintaining the LinuxSH webpages?

[Alex B. <al...@be...>]

I've just been syncing up my local tree to the latest linuxsh/marcello
trees and I've noticed the webpages on CVS are out of date (they still
refer to the "kernel" project instead of the correct "linux").

I would also recommend putting the anonymous check out details on the
page. Something like:

To obtain the latest 2.4 drop-in tree from CVS (unless you are tracking
the development kernel) do the following steps in an empty directory:

    cvs -d:pserver:ano...@cv...:/cvsroot/linuxsh login

Hit return when prompted for a password, there is none. Next do:

   cvs -z3 -d:pserver:ano...@cv...:/cvsroot/linuxsh co
linux -r linux-2_4-branch

And wait for the checkout to complete. Anonymous CVS may fail at busy
times as Sourceforge ensure developers have access (via ssh) over
ananymous users. Just try again later if it fails.

Once you have your drop in tree checked out you can bring it upto date
with the latest changes by executing:

    cvs update -dP

If new files have been added you may need to re-run the drop-in script.

-- 
Alex, homepage: http://www.bennee.com/~alex/

If men acted after marriage as they do during courtship, there would
be fewer divorces -- and more bankruptcies.
		-- Frances Rodman

[linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

[Paul M. <le...@li...>]

On Thu, Jun 12, 2003 at 05:35:23PM +0900, kaz Kojima wrote:
> The problem is the meaning of the macro __sh3__ and __SH4__. If they
> simply means CPU, you are right. But if they means ABI, the current
> -m4-nofpu does the correct thing, because the purpose of -m4-nofpu is
> to make programs having SH-3 like ABI and working on SH-4 CPU.
> It would be better to separate these two meanings.
>=20
It would also be better to more clearly define -m4-nofpu. The whole __sh3__=
 and
__SH4_NOFPU__ thing as it stands right now is one giant mess. The name itse=
lf
is utterly misleading, though is likely quite a bit cleaner than something
like using -mtune to adjust the ABI level. I definitely like the SHmedia
definitions quite a bit better.

I would also presume that SH-4 without FP should be mostly ABI compatible w=
ith
the SH-3. In which case, applications built with -m3 should presumably work=
 to
some degree. (I'm at least able to run -m2 and -m3 compiled applications).

Either way, I suppose going the -mno-implicit-fp route is probably the way =
to
go. It would be nice to get this merged with 3.3/3.4 definitely, as this sh=
ould
leave us with a working toolchain from stock gcc.

> >As a workaround for some of this stupidity, I went through and changed m=
ost of
> >the __sh3__ and __SH4__ checks to CONFIG_CPU_SH3 and CONFIG_CPU_SH4 -- s=
ince
> >obviously we can't rely on GCC to be correct.
>=20
> So, it might be not only a workaround but also the Right Thing.=20
>=20
I'll do this for the 2.4 branch as well then and see if things still work.

Re: [linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

[David W. <dw...@in...>]

On Thu, 2003-06-12 at 02:58, kaz Kojima wrote:
> You can find the arguments starting from
>   <URL:http://gcc.gnu.org/ml/gcc/2002-10/msg00700.html>.
> It's for powerpc, but explains why no-implicit-fp option doesn't
> exist in FSF code. Ah, It reminds me why I tried to forget about
> this option :-)

Mark Mitchell said "I agree, on all points... Clearly, many people have
a real need for this functionality." 

I think the fact that it's happening now for both PPC and SH is
indicative that it shouldn't be a machine-specific option. The only
reason that GCC doesn't use FP on other platforms is because it hasn't
yet found a case in which it's faster to do so. I can imagine it
starting to use SSE and similar stuff on i386, in future, etc.

GCC should probably have a '-mno-implicit-fp' option in _generic_ code,
and it can have no effect on those back ends which haven't yet learned
how to make use of the floating point unit without explicitly being
asked to.

-- 
dwmw2

[linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

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

Paul Mundt <le...@li...> wrote:
>Ideally it would be nice if -m4-nofpu actually did the -U__sh3__ -D__SH4__ by
>default, since obviously one would assume that -m4 indicates SH-4. Fixing
>broken GCC behavior would seem to be a more useful practice then attempting to
>hack around it in the kernel (we already do enough of that!).

The problem is the meaning of the macro __sh3__ and __SH4__. If they
simply means CPU, you are right. But if they means ABI, the current
-m4-nofpu does the correct thing, because the purpose of -m4-nofpu is
to make programs having SH-3 like ABI and working on SH-4 CPU.
It would be better to separate these two meanings.

>As a workaround for some of this stupidity, I went through and changed most of
>the __sh3__ and __SH4__ checks to CONFIG_CPU_SH3 and CONFIG_CPU_SH4 -- since
>obviously we can't rely on GCC to be correct.

So, it might be not only a workaround but also the Right Thing. 

Regards,
	kaz

[linuxsh-dev] Re: [linux-sh:02783] Re: Where does __sdivsi3_i4 come from?

[Paul M. <le...@li...>]

On Thu, Jun 12, 2003 at 09:51:14AM +0900, kaz Kojima wrote:
> BTW, we don't have even local patches for -mno-implicit-fp against
> gcc-3.3 and gcc-3.4. I hear that the "stage1" of gcc-3.4 will end at
> July 4 and it means that we can't add any new features to the official
> gcc-3.4 after that day. I'm unsure that there are technical merits to
> use them when compiling kernel, but some folks would like to use a
> single (and new) SH gcc.
> Sugioka-san taught me that the option
>=20
>   -m4-nofpu -U__sh3__ -D__SH4__=3D1
>=20
> works for the kernel, at least to some extent. It slightly changes
> the ABI of function calling conventions even for the integer arguments,
> so we might need to check that it doesn't break something, though I
> guess there are few possibilities and we can easily fix them if any.
> So, it might be enough for the kernel and the kernel modules.
> # Caveat: Don't use -m4-nofpu for userland works without the complete
> #         understanding about this option.
>=20
> The third way might be to rewrite kernel so as to enable the use of FPU
> by kernel itself, though it'd be the another issue.
>=20
> Opinions?

Ideally it would be nice if -m4-nofpu actually did the -U__sh3__ -D__SH4__ =
by
default, since obviously one would assume that -m4 indicates SH-4. Fixing
broken GCC behavior would seem to be a more useful practice then attempting=
 to
hack around it in the kernel (we already do enough of that!).

As a workaround for some of this stupidity, I went through and changed most=
 of
the __sh3__ and __SH4__ checks to CONFIG_CPU_SH3 and CONFIG_CPU_SH4 -- since
obviously we can't rely on GCC to be correct.

With most of that inplace, I'm able to build and boot for 2.4 (and 2.5 last
time I checked).

[linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

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

Dan Kegel <dk...@ix...> wrote:
> As for gcc-3.4 ... since earlier compilers had -mno-implicit-fp,
> couldn't you consider this a bugfix rather than a feature? :-)

Maybe all sh-linux folks will think so :-)
But it exists only locally patched gcc including the recent Debian
gcc-3.2.x sources and Sugioka-san's toolchain.

You can find the arguments starting from
  <URL:http://gcc.gnu.org/ml/gcc/2002-10/msg00700.html>.
It's for powerpc, but explains why no-implicit-fp option doesn't
exist in FSF code. Ah, It reminds me why I tried to forget about
this option :-)

Regards,
	kaz

[linuxsh-dev] Re: [linux-sh:02783] Re: Where does __sdivsi3_i4 come from?

[Dan K. <dk...@ix...>]

kaz Kojima wrote:
> Stuart Menefy <stu...@st...> wrote:
> 
>>You need to build kernel modules with the -mno-implicit-fp compiler
>>option. This is the same option used when building the kernel, and
>>prevents the compiler making use of the floating point unit for integer
>>divides. It also effects which intrinsic functions the compiler uses
>>for integer divide, which is what you are seeing here.
> 
> 
> BTW, we don't have even local patches for -mno-implicit-fp against
> gcc-3.3 and gcc-3.4. I hear that the "stage1" of gcc-3.4 will end at
> July 4 and it means that we can't add any new features to the official
> gcc-3.4 after that day. I'm unsure that there are technical merits to
> use them when compiling kernel, but some folks would like to use a
> single (and new) SH gcc.

I would very much like to use gcc-3.3 for compiling everything,
including the sh-4 kernel.  But I guess I will plan on using gcc-3.2.3
for that for now, after reading your message!

As for gcc-3.4 ... since earlier compilers had -mno-implicit-fp,
couldn't you consider this a bugfix rather than a feature? :-)
- Dan

[linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

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

Stuart Menefy <stu...@st...> wrote:
> You need to build kernel modules with the -mno-implicit-fp compiler
> option. This is the same option used when building the kernel, and
> prevents the compiler making use of the floating point unit for integer
> divides. It also effects which intrinsic functions the compiler uses
> for integer divide, which is what you are seeing here.

BTW, we don't have even local patches for -mno-implicit-fp against
gcc-3.3 and gcc-3.4. I hear that the "stage1" of gcc-3.4 will end at
July 4 and it means that we can't add any new features to the official
gcc-3.4 after that day. I'm unsure that there are technical merits to
use them when compiling kernel, but some folks would like to use a
single (and new) SH gcc.
Sugioka-san taught me that the option

  -m4-nofpu -U__sh3__ -D__SH4__=1

works for the kernel, at least to some extent. It slightly changes
the ABI of function calling conventions even for the integer arguments,
so we might need to check that it doesn't break something, though I
guess there are few possibilities and we can easily fix them if any.
So, it might be enough for the kernel and the kernel modules.
# Caveat: Don't use -m4-nofpu for userland works without the complete
#         understanding about this option.

The third way might be to rewrite kernel so as to enable the use of FPU
by kernel itself, though it'd be the another issue.

Opinions?

[linuxsh-dev] Re: [linux-sh:02781] Re: Where does __sdivsi3_i4 come from?

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

You need to build kernel modules with the -mno-implicit-fp compiler
option. This is the same option used when building the kernel, and
prevents the compiler making use of the floating point unit for integer
divides. It also effects which intrinsic functions the compiler uses
for integer divide, which is what you are seeing here.

Stuart


On Tue, 10 Jun 2003 16:17:06 +0100 ker...@be... wrote:

> On Tue, 2003-06-10 at 16:12, Vincent Rubiolo wrote:
> > Hi,
> > 
> > Did you check that you are correctly linking against libgcc? IIRC, these symbs are used by libgcc to 
> > emulate math hardware instructions (yours should be about division, obviously) if they are not found 
> > on a certain architecture.
> 
> Well kernel modules don't explicitly link to libgcc, they can only use
> symbols exported by the kernel. In my case the kernel exports __sdivsi3
> but the module compile generated  __sdivsi3_i4 which obviously fails to
> link.
> 
> Also adding to the confusion is why the compiler feels the need to do a
> division for a *particular* function call where other calls to the
> *same* function do not cause this code to be generated. 
> 
> > Hopes that helps,
> 
> A bit thanks. Now at least I know what it is, but not why its trying to
> do it.
> 
> -- 
> Alex, homepage: http://www.bennee.com/~alex/
> 
> When all else fails, read the instructions.
> 

[linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

[Alex B. <ker...@be...>]

On Tue, 2003-06-10 at 16:12, Vincent Rubiolo wrote:
> Hi,
> 
> Did you check that you are correctly linking against libgcc? IIRC, these symbs are used by libgcc to 
> emulate math hardware instructions (yours should be about division, obviously) if they are not found 
> on a certain architecture.

Well kernel modules don't explicitly link to libgcc, they can only use
symbols exported by the kernel. In my case the kernel exports __sdivsi3
but the module compile generated  __sdivsi3_i4 which obviously fails to
link.

Also adding to the confusion is why the compiler feels the need to do a
division for a *particular* function call where other calls to the
*same* function do not cause this code to be generated. 

> Hopes that helps,

A bit thanks. Now at least I know what it is, but not why its trying to
do it.

-- 
Alex, homepage: http://www.bennee.com/~alex/

When all else fails, read the instructions.

[linuxsh-dev] Re: Where does __sdivsi3_i4 come from?

[Vincent R. <vin...@st...>]

Hi,

Did you check that you are correctly linking against libgcc? IIRC, these symbs are used by libgcc to 
emulate math hardware instructions (yours should be about division, obviously) if they are not found 
on a certain architecture.

Hopes that helps,

Vincent

ker...@be... wrote:

> Hi,
> 
> I'm currently porting the isp1161 usb driver to my SH kernel and I've
> come across a bizare symbol problem.
> 
> When I try to insmod the compiled module I get the following error:
> 
> root@192.168.0.230:/test# insmod hc_isp116x.o
> hc_isp116x.o: unresolved symbol __sdivsi3_i4
> 
> I can get the line to disappear by commenting out the function call, but
> I have no idea what causes it as the function is currently NULL and
> called from three other places in the code without causing the failure.
> If looked at the .s output put asside from seeing the function call made
> I can't figure out what line of code is causing this. 
> 
> I did some grepping in the kernel and found this
> 
> ./arch/sh/kernel/sh_ksyms.c:DECLARE_EXPORT(__sdivsi3);
> 
> with the comment that:
> /* These symbols are generated by the compiler itself */
> 
> So far googling hasn't enlightend me. Anyone got any ideas? Appologies
> for the gratuitous cross-posting but I'm unsure if this is a gcc or sh
> issue.
> 

[linuxsh-dev] Re: [linux-sh:02780] Where does __sdivsi3_i4 come from?

[Daniel J. <dr...@mv...>]

On Tue, Jun 10, 2003 at 03:55:19PM +0100, Alex Bennee wrote:
> Hi,
> 
> I'm currently porting the isp1161 usb driver to my SH kernel and I've
> come across a bizare symbol problem.
> 
> When I try to insmod the compiled module I get the following error:
> 
> root@192.168.0.230:/test# insmod hc_isp116x.o
> hc_isp116x.o: unresolved symbol __sdivsi3_i4
> 
> I can get the line to disappear by commenting out the function call, but
> I have no idea what causes it as the function is currently NULL and
> called from three other places in the code without causing the failure.
> If looked at the .s output put asside from seeing the function call made
> I can't figure out what line of code is causing this. 
> 
> I did some grepping in the kernel and found this
> 
> ./arch/sh/kernel/sh_ksyms.c:DECLARE_EXPORT(__sdivsi3);
> 
> with the comment that:
> /* These symbols are generated by the compiler itself */
> 
> So far googling hasn't enlightend me. Anyone got any ideas? Appologies
> for the gratuitous cross-posting but I'm unsure if this is a gcc or sh
> issue.

It comes from libgcc.  Current SH kernels (at least in 2.5) export
it...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[linuxsh-dev] Where does __sdivsi3_i4 come from?

[Alex B. <ker...@be...>]

Hi,

I'm currently porting the isp1161 usb driver to my SH kernel and I've
come across a bizare symbol problem.

When I try to insmod the compiled module I get the following error:

root@192.168.0.230:/test# insmod hc_isp116x.o
hc_isp116x.o: unresolved symbol __sdivsi3_i4

I can get the line to disappear by commenting out the function call, but
I have no idea what causes it as the function is currently NULL and
called from three other places in the code without causing the failure.
If looked at the .s output put asside from seeing the function call made
I can't figure out what line of code is causing this. 

I did some grepping in the kernel and found this

./arch/sh/kernel/sh_ksyms.c:DECLARE_EXPORT(__sdivsi3);

with the comment that:
/* These symbols are generated by the compiler itself */

So far googling hasn't enlightend me. Anyone got any ideas? Appologies
for the gratuitous cross-posting but I'm unsure if this is a gcc or sh
issue.

-- 
Alex, homepage: http://www.bennee.com/~alex/

76. I have never seen it do *that* before...

	--Top 100 things you don't want the sysadmin to say

[linuxsh-dev] Execute in place.

[David W. <dw...@in...>]

I've done some work on kernel XIP. The basic principle of operation is
that we copy any code which may need to run while the flash chips are in
anything but 'read' mode into RAM, and we disable interrupts while the
chips are busy. During erases, we poll not only for erase completion but
also for pending IRQs. If an IRQ is pending, we suspend the erase
operation, re-enable IRQs and call cond_resched().

The flash driver code is fairly simple, although it wants a little bit
of cleanup and I want to be convinced that the arch-specific bits are
done right before committing it. 

The arch-specific parts are implemented for XScale only so far, but
should be relatively simple to do for new architectures. You need to
ensure that parts of kernel code can be loaded into RAM instead of ROM,
when marked with the '__xipram' attribute, that the udelay() function is
in that section, and also your software TLB handlers if you have them --
or indeed anything else which may be needed in the critical sections of
the flash chip driver. I've reintroduced the get_unaligned() macro to
potentially-unaligned data loads in the critical region, so alignment
fixups do _not_ need to be in RAM. 

You also need to provide suitable xip_cli(), xip_sti(), and
xip_irqpending() functions or macros in include/linux/mtd/xip.h. I
suspect that wants moving to include/asm-$(ARCH)/xip.h or similar.

It's implemented for Intel command set chips only so far; adding similar
support to the other command sets is left as an exercise for the reader.
Two patches attached -- the arch-specific patch to 2.4.19-rmk7-pxa1 to
provide the generic .xipram support, and the patch against MTD CVS to
add the chip support.

Comments welcome.

-- 
dwmw2

Re: [linuxsh-dev] Re: [linux-sh:02750] Re: [PATCH] Ensure flush_page_to_ram does

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

On Tue, 20 May 2003 14:59:22 +0100 ker...@be... wrote:

> On Tue, 2003-05-20 at 14:40, Stuart Menefy wrote:
> > Alex
> > 
> > Abe-san found a similar problem when using my TLB miss handling patches.
> > When using PIO there is no cache synchronisation in the generic IDE code,
> > while NFS has an explicit call to flush_dcache_page.
> 
> Well thats good. I guess there are two ways to crack this nut. I forgot
> to mention I'm also using your enhanced TLB miss patches - i take it the
> impication is that the old TLB handler didn't see these problems?

I don't remember seeing any, either personally or reported to the list.
However I've not run without my patches for some time now, and we don't
use IDE much. If its any help, SCSI disks appears to be rock solid.

> Are there any other issues with the TLB handler which are still keeping
> it out of the mainline (LinuxSH) tree?

Not really. I was hoping to get some wider testing, but I think there has
been as much as I can reasonably expect given that it involves applying
patches. So maybe I should just bite the bullet, check it in, and wait for
the screams!

Peter Garrone did a port to 2.5.13 a while ago, this should probably also
be brought up to date (if necessary) and applied to the 2.5 branch.

> > The solution we tried which has worked so far is based on the Sparc code,
> > which redefines the IO functions to include a cache synchronisation call.
> > The patch is attached. 
> 
> I guess by concentrating on just the IDE part this patch is more
> efficent as the cache is only flushed for the IDE operations rather than
> every time a file is mapped in. Is this scheduled to go into the LinuxSH
> tree?

Thats right. Plus the IDE use of insl/outsl is very predictable (its only
ever used for sector sized chunks into the buffer cache). I wouldn't
want to change the normal I/O functions as the overhead would be too high,
and would be unexpected in other circumstances.

I'll check this in at the same time as the cache related changes.

Stuart

Re: [linuxsh-dev] Re: [linux-sh:02749] [PATCH] Ensure flush_page_to_ram does

[Paul M. <le...@li...>]

On Tue, May 20, 2003 at 02:40:44PM +0100, Stuart Menefy wrote:
> Abe-san found a similar problem when using my TLB miss handling patches.
> When using PIO there is no cache synchronisation in the generic IDE code,
> while NFS has an explicit call to flush_dcache_page.
> 
> The solution we tried which has worked so far is based on the Sparc code,
> which redefines the IO functions to include a cache synchronisation call.
> The patch is attached. 
> 
This certainly looks like a better solution, especially given that
flush_page_to_ram() is deprecated in 2.5.

Does this problem only happen when using the tlbmiss patches? Or is it
reproduceable under the current 2.4/2.5 branches?

[linuxsh-dev] Re: [linux-sh:02750] Re: [PATCH] Ensure flush_page_to_ram does

[Alex B. <ker...@be...>]

On Tue, 2003-05-20 at 14:40, Stuart Menefy wrote:
> Alex
> 
> Abe-san found a similar problem when using my TLB miss handling patches.
> When using PIO there is no cache synchronisation in the generic IDE code,
> while NFS has an explicit call to flush_dcache_page.

Well thats good. I guess there are two ways to crack this nut. I forgot
to mention I'm also using your enhanced TLB miss patches - i take it the
impication is that the old TLB handler didn't see these problems?

Are there any other issues with the TLB handler which are still keeping
it out of the mainline (LinuxSH) tree?

> The solution we tried which has worked so far is based on the Sparc code,
> which redefines the IO functions to include a cache synchronisation call.
> The patch is attached. 

I guess by concentrating on just the IDE part this patch is more
efficent as the cache is only flushed for the IDE operations rather than
every time a file is mapped in. Is this scheduled to go into the LinuxSH
tree?

-- 
Alex, homepage: http://www.bennee.com/~alex/

Doubt is a pain too lonely to know that faith is his twin brother.
- Kahlil Gibran

[linuxsh-dev] Re: [linux-sh:02749] [PATCH] Ensure flush_page_to_ram does

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

Alex

Abe-san found a similar problem when using my TLB miss handling patches.
When using PIO there is no cache synchronisation in the generic IDE code,
while NFS has an explicit call to flush_dcache_page.

The solution we tried which has worked so far is based on the Sparc code,
which redefines the IO functions to include a cache synchronisation call.
The patch is attached. 

Abe-san has seen some problems when using DMA, which I've not been able
to reproduce here, but PIO appears fine now.

Stuart


On Tue, 20 May 2003 11:07:42 +0100 ker...@be... wrote:

> Hi,
> 
> The reason we where seeing issues with executing from hard disk was due
> to cache behaviour. We fixed it by applying this patch:
> 
> --- ../../../linuxsh-2.4/include/asm-sh/pgtable.h       2003-04-10
> 17:19:24.000000000 +0100
> +++ pgtable.h   2003-05-20 10:56:26.000000000 +0100
> @@ -62,7 +62,7 @@
>  extern void flush_icache_range(unsigned long start, unsigned long end);
>  extern void flush_cache_sigtramp(unsigned long addr);
>   
> -#define flush_page_to_ram(page)                        do { } while (0)
> +#define flush_page_to_ram(page)                       
> flush_dcache_page(page)
>  #define flush_icache_page(vma,pg)              do { } while (0)
>   
>  /* Initialization of P3 area for copy_user_page */
> 
> To ensure the data loaded from disk (with PIO) was properly cached in
> the processor. We think this issue was avoided with booting from NFS
> because of different cache behaviour when DMA is involved.
> 
> flush_page_to_ram is a deprecated function but thats something that
> would need to be sorted out in the main tree. Comments?
> 
> -- 
> Alex, homepage: http://www.bennee.com/~alex/
> 
> There are only two kinds of men -- the dead and the deadly.
> 		-- Helen Rowland
> 

[linuxsh-dev] [PATCH] Ensure flush_page_to_ram does

[Alex B. <ker...@be...>]

Hi,

The reason we where seeing issues with executing from hard disk was due
to cache behaviour. We fixed it by applying this patch:

--- ../../../linuxsh-2.4/include/asm-sh/pgtable.h       2003-04-10
17:19:24.000000000 +0100
+++ pgtable.h   2003-05-20 10:56:26.000000000 +0100
@@ -62,7 +62,7 @@
 extern void flush_icache_range(unsigned long start, unsigned long end);
 extern void flush_cache_sigtramp(unsigned long addr);
  
-#define flush_page_to_ram(page)                        do { } while (0)
+#define flush_page_to_ram(page)                       
flush_dcache_page(page)
 #define flush_icache_page(vma,pg)              do { } while (0)
  
 /* Initialization of P3 area for copy_user_page */

To ensure the data loaded from disk (with PIO) was properly cached in
the processor. We think this issue was avoided with booting from NFS
because of different cache behaviour when DMA is involved.

flush_page_to_ram is a deprecated function but thats something that
would need to be sorted out in the main tree. Comments?

-- 
Alex, homepage: http://www.bennee.com/~alex/

There are only two kinds of men -- the dead and the deadly.
		-- Helen Rowland

[linuxsh-dev] RE: [linux-sh:02742] Re: new board for 2.5.69

[<ks...@in...>]

Thanks for reviewing our patch and sorry for the bad use of
some deprecated features. I'd like to look into the new pcibios
interface.
Thanks again for your valuable suggestions.

------------
Saito.K

>Secondly, the old pcibios interface is also deprecated. We're using the
>PCI auto interface now, though some of the boards are still pending
>updating. See the Dreamcast code for an example of how to 
>integrate your
>changes with the new API. I suppose the hack to 
>pcibios_align_resource()
>will still be needed though, but to arch/sh/kernel/pci.c instead.
>
>The rest of it looks good, since the pci code is the only
>save_and_cli()/restore_flags() user, I'll merge the rest of the patch
>for the time being, and will merge the pci code once its been cleaned
>up.
>

[linuxsh-dev] [RFC] machtype generation

[Paul M. <le...@li...>]

This issue was initially brought up in the deviceinfo thread about a
month ago, at which point I noted that I had a local script I was
playing with to see about doing automatic machtype generation to clean
up quite a bit of the include/asm-sh/machvec.h mess.

At the moment, the current interface looks like the following:

	- Add a 1-bit value to sh_machine_vector to flag your
	  current board type
	- Define MACH_xxx repeatedly through endless ifdefs to
	  determine the current board type (also wrap through
	  the sh_machine_vector struct if CONFIG_SH_GENERIC is
	  set).

This approach is ugly for quite a lot of reasons, least of all the fact
that everytime a new board is added, structure size changes, and more of
these ugly macros are generated.

As a solution to this, I've essentially created a stripped-down clone of
the ARM tree's mach type generation script. For this interface, I
propose that we maintain a master-list of supported boards and their
associated CONFIG options in some place like arch/sh/tools/mach-types.

As an initial implementation, I have mach-types looking something like
this:

	#
	# List of boards.
	#

	#
	# MACH_<xxx>		CONFIG_<xxx>
	#
	SE			SH_SOLUTION_ENGINE
	7751SE			SH_7751_SOLUTION_ENGINE		
	HP600			SH_HP600
	HP620			SH_HP620
	HP680			SH_HP680
	HP690			SH_HP690
	HD64461			HD64461
	HD64465			HD64465
	SH2000			SH_SH2000
	SATURN			SH_SATURN
	DREAMCAST		SH_DREAMCAST
	BIGSUR			SH_BIGSUR
	ADX			SH_ADX


I suppose some more work could be done here to simplify things further
(or potentially elaborate some more), but as I said, this is just an
initial implementation.

This list will then be passed through a script that will be invoked by
arch/sh/Makefile early-on (probably at the same time that the symlinks
in include/asm-sh are made), and will generate include/asm-sh/machtype.h
automatically. This header can then be referenced directly and we can
sanely gut most of machvec.h.

As an example of an auto-generated machtype.h, I have the following:

	/*
	 * Automagically generated, don't touch.
	 */
	#ifndef __ASM_SH_MACHTYPE_H
	#define __ASM_SH_MACHTYPE_H

	/*
	 * We'll use the following MACH_xxx defs for placeholders for
	 * the time being .. these will all go away once sh_machtype is
	 * assigned per-board.
	 *
	 * For now we leave things the way they are for backwards
	 * compatibility.
	 */

	/* Mach types */
	#ifdef CONFIG_SH_SOLUTION_ENGINE
	  #define MACH_SE		1
	#else
	  #define MACH_SE		0
	#endif
	#ifdef CONFIG_SH_7751_SOLUTION_ENGINE
	  #define MACH_7751SE		1
	#else
	  #define MACH_7751SE		0
	#endif
	#ifdef CONFIG_SH_HP600
	  #define MACH_HP600		1
	#else
	  #define MACH_HP600		0
	#endif
	#ifdef CONFIG_SH_HP620
	  #define MACH_HP620		1
	#else
	  #define MACH_HP620		0
	#endif
	#ifdef CONFIG_SH_HP680
	  #define MACH_HP680		1
	#else
	  #define MACH_HP680		0
	#endif
	#ifdef CONFIG_SH_HP690
	  #define MACH_HP690		1
	#else
	  #define MACH_HP690		0
	#endif
	#ifdef CONFIG_HD64461
	  #define MACH_HD64461		1
	#else
	  #define MACH_HD64461		0
	#endif
	#ifdef CONFIG_HD64465
	  #define MACH_HD64465		1
	#else
	  #define MACH_HD64465		0
	#endif
	#ifdef CONFIG_SH_SH2000
	  #define MACH_SH2000		1
	#else
	  #define MACH_SH2000		0
	#endif
	#ifdef CONFIG_SH_SATURN
	  #define MACH_SATURN		1
	#else
	  #define MACH_SATURN		0
	#endif
	#ifdef CONFIG_SH_DREAMCAST
	  #define MACH_DREAMCAST	1
	#else
	  #define MACH_DREAMCAST	0
	#endif
	#ifdef CONFIG_SH_BIGSUR
	  #define MACH_BIGSUR		1
	#else
	  #define MACH_BIGSUR		0
	#endif
	#ifdef CONFIG_SH_ADX
	  #define MACH_ADX		1
	#else
	  #define MACH_ADX		0
	#endif

	/* Machtype checks */
	#define mach_is_se()			(MACH_SE)
	#define mach_is_7751se()		(MACH_7751SE)
	#define mach_is_hp600()			(MACH_HP600)
	#define mach_is_hp620()			(MACH_HP620)
	#define mach_is_hp680()			(MACH_HP680)
	#define mach_is_hp690()			(MACH_HP690)
	#define mach_is_hd64461()		(MACH_HD64461)
	#define mach_is_hd64465()		(MACH_HD64465)
	#define mach_is_sh2000()		(MACH_SH2000)
	#define mach_is_saturn()		(MACH_SATURN)
	#define mach_is_dreamcast()		(MACH_DREAMCAST)
	#define mach_is_bigsur()		(MACH_BIGSUR)
	#define mach_is_adx()			(MACH_ADX)

	#endif /* __ASM_SH_MACHTYPE_H */

Also, if anyone is interested in the script for this, its nothing
special, and is more or less just a quick and dirty hack. I've attached
that as well, incase anyone wants to look it over.

I realize this doesn't fixup the ifdef mess, but as noted in the
comments above, its a temporary fix until something like sh_machtype
gets introduced, and can then be set in board-specific setup code.

If no one has any problems with this, I'll merge it into HEAD in the
next few days.

Comments?

[linuxsh-dev] Re: [linux-sh:02739] new board for 2.5.69

[Paul M. <le...@li...>]

On Fri, May 16, 2003 at 03:19:53PM +0900, ks...@in... wrote:
> We ported CVS HEAD to our mpc1211 hardware. Now it works very well
> with almost i/o the board has, including USB devices. Can we
> contribute it to LinuxSH, if it's ok?
> 
This looks good, though I have a few suggestions.

For starters, save_and_cli()/restore_flags() are deprecated, please
don't use them. I killed support for these in HEAD quite awhile ago, so
as-is, your code won't compile in current HEAD. (This is a trivial fix
though, as local_irq_save()/local_irq_restore() will do what you want).

Secondly, the old pcibios interface is also deprecated. We're using the
PCI auto interface now, though some of the boards are still pending
updating. See the Dreamcast code for an example of how to integrate your
changes with the new API. I suppose the hack to pcibios_align_resource()
will still be needed though, but to arch/sh/kernel/pci.c instead.

Another, mostly cosmetic issue, in arch/sh/Makefile, there's no need to
define incdir-y for your board. The only reason this exists is for
boards who have a different name in include/asm-sh then they do in
arch/sh/boards. ie, the SolutionEngine7751 code resides in
arch/sh/boards/se/7751 and has its headers under include/asm-sh/se7751.
This is needed to make the board symlink, so asm/mach will reference
whatever current board you have the kernel configured for.

The rest of it looks good, since the pci code is the only
save_and_cli()/restore_flags() user, I'll merge the rest of the patch
for the time being, and will merge the pci code once its been cleaned
up.

[linuxsh-dev] new board for 2.5.69

[<ks...@in...>]

Hi,

We ported CVS HEAD to our mpc1211 hardware. Now it works very well
with almost i/o the board has, including USB devices. Can we
contribute it to LinuxSH, if it's ok?

The attached list is the ChangeLog of this patch. The patch itself
is slightly big to attach here as a plain text, so I put it at:
<URL:
http://www12.ocn.ne.jp/~ifpublib/sh-linux/mpc1211-20030514.patch.bz2>

Here is the ChangeLog entries:

	* arch/sh/Kconfig: Add mpc1211 support.
	* arch/sh/Makefile: Add mpc1211 support.
	* arch/sh/boards/mpc1211/Makefile: New file.
	* arch/sh/boards/mpc1211/io.c: New file.
	* arch/sh/boards/mpc1211/led.c: New file.
	* arch/sh/boards/mpc1211/mach.c: New file.
	* arch/sh/boards/mpc1211/pci.c: New file.
	* arch/sh/boards/mpc1211/rtc.c: New file.
	* arch/sh/boards/mpc1211/setup.c: New file.
	* arch/sh/kernel/Makefile: Add mpc1211 support.
	* arch/sh/kernel/pcibios.c: Add mpc1211 support.
	* arch/sh/kernel/sh_ksyms.c (memscan, __copy_user, __udivdi3,
	__flush_purge_region, __down_trylock): Add to exported symbols.
	* arch/sh/vmlinux.lds.S: Add mpc1211 support.

	* drivers/char/keyboard.c: Add mpc1211 support.
	* drivers/ide/Kconfig: Add mpc1211 support.
	* drivers/ide/pci/alim15x3.c: Add mpc1211 support.
	* drivers/mtd/chips/jedec_probe.c: Add Fujitsu MBM29F040C
support.
	* drivers/mtd/maps/Kconfig: Add mpc1211 support.
	* drivers/mtd/maps/Makefile: Add mpc1211 support.
	* drivers/mtd/maps/mpc1211.c: Add mpc1211 support.
	* drivers/video/Kconfig: Add Chips 69000 display support.
	* drivers/video/Makefile: Add Chips 69000 display support.
	* drivers/video/asiliantfb.c: New file.
	* drivers/video/fbmem.c: Add Chips 69000 display support.

	* include/asm-sh/dma.h: Add mpc1211 support.
	* include/asm-sh/floppy.h: New file.
	* include/asm-sh/irq.h: Add mpc1211 support.
	(irq_canonicalize): here as an inline function.
	* include/asm-sh/keyboard.h: Add mpc1211 support.
	* include/asm-sh/machvec.h: Add mpc1211 support.
	* include/asm-sh/mc146818rtc.h: Add mpc1211 support.
	* include/asm-sh/mpc1211/dma.h: New file.
	* include/asm-sh/mpc1211/io.h: New file.
	* include/asm-sh/mpc1211/keyboard.h: New file.
	* include/asm-sh/mpc1211/m1543c.h: New file.
	* include/asm-sh/mpc1211/mc146818rtc.h: New file.
	* include/asm-sh/mpc1211/mpc1211.h: New file.
	* include/asm-sh/mpc1211/pci.h: New file.
	* include/asm-sh/pci.h: Add mpc1211 support.
	(sg_dma_address): Fix typo.
	* include/asm-sh/scatterlist.h: Copy from kernel.org.
	* include/linux/pci_ids.h: Add Chips 69000 display support.


P.S.

Linux v2.5.69 kernel runs well on the CPU boards 
(mpc1211; nickname for CTP-SH02, PCI-SH02 and MPC-SH02) 
produced by Interface Corporation.

I embedded driver for keyboard, mouse, LAN, fb and HDD into kernel using
make.
I built it so that FDD, serial port, mtd and USB-CD could be used as
module. 
It works well except USB-CD. X Window system runs very comfortably.

Module for USB-CD (usbcore, ohci_hcd, usb_storage) freeze the systems
when rmmod command worked.

I downloaded UserLand from debian.dodes.org. 
I also downloaded kernel.org/people/rusty/modules/module-init-tools-0.9.
11a.tar.bz2 
and use it for modules that was self-compiled by SHLinux

Boot device is HDD, and I can also use nfs-root to boot.

The differences the kernel resource I have used and the original(kernel.
org) 2.5.69 
are merged into the following Kojima-san's patch.
<URL: http://dodo.nurs.or.jp/~kkojima/linux-sh4/patch-2.5.69-local.diff.
bz2>


------
Saito
------
I can't understand English, so my friend translated these sentences
Japanese into English for me.
If I had any maintainers who could understand Japanese, I could have
communication with them.

[linuxsh-dev] Re: [linux-sh:02735] Anybody used ext2 on SH?

[Dan K. <da...@ke...>]

Alex Bennee wrote:
> We've been testing our IDE interace on our SH based board and everything
> was works fine except we occasionaly get crashes with code running off
> the hard disk. We originally though it may be a problem with our IDE
> code but it seems the fault is ext2 related as we can get the same
> failure mode over ext2 on a loopback over nfs.
> 
> Have many people been using ext2 on SH platforms? 

We're using ext2 on sh4, but only just barely; we use genext2fs
to generate an ext2 boot image, and after boot, we pivot_root
to tmpfs.  But ext2 works well for the fifty milliseconds we
use it :-)
- Dan


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[linuxsh-dev] mmap/ remap_page_range problem with SH3 big endian

[alain v. <av...@ya...>]

Hello guys,

well actually I don't know if the problem comes from
SH3 or not but I thought it's a good idea to ask you.

I got problems while using remap_page_range with
mmap/nopage handler. Let me try to describe you what
I'm trying to achieve. I got a custom video card which
has his video memory paged (need to set video card
registers in order to get an area of this memory
directly accessible to the SH3 from address
0xa8000000). Since I need to make this memory
accessible (in a linear way .. sorry I forgot to tell
you that it's a framebuffer driver) from userland, I
was trying to achieve that by using nopage handler
with remap_page_range function.

My nopage function looks like this:

struct page* my_nopage(struct vm_area_struct *vma,
unsigned long address, int no_share)
{
  pgd_t *pgd;
  pmd_t *pmd;
  pte_t *pte;
  unsigned long phys_add;

  /* Set register of the video card to make an area of
the video memory accessible from the SH3 */
  { .... }

  /* Calculate the physical memory address */
  phys_add = {.....}

  /* FIXME ... is it useful in something ??? */
  /* Pages shouldn't be cached */
  vma->vm_page_prot =
pgprot_noncached(vma->vm_page_prot);

  remap_page_range(address & PAGE_MASK, phys_add,
PAGE_SIZE, vma->vm_page_prot);

  pgd = pgd_offset(current->mm, address);
  pmd = pmd_offset(pgd, address);
  pte = pte_offset(pmd, address);

  return pte_page(*pte);
}

The mmap function doesn't do actually to many things
except set the nopage handler.
Everything is done in the nopage handler.

From user space, when I mmap the framebuffer, I can
access to the video memory
...... ONCE. I mean, the mmap function will return a
pointer, using this pointer
I'll be able to read/write into the video memory. For
example I can set all bytes
of the video memory from 0 the end once (lot of nopage
handler will be called)
but then if I try to set once again, the nopage
handler will never be called again.

Well, once again, I don't know if it's a problem due
to the SH or just some 
misunderstanding on the way to use remap_page_range; I
was hoping someone could
confirm this to me, and hopefully tell me what is
wrong.
I hope it's not too difficult to understand my saying.

Sincerely,
Alain Volmat

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com