linuxsh-dev

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

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

Hey guys,

On Wed, 25 Oct 2000, YAEGASHI Takeshi wrote:

> Hello Rene,
> 
> In the article <39F...@li...>,
> Rene Malmgren <re...@li...> wrote:
> 
> > Can someone please tell me what works and what doesn't yet, and how do
> > you get it to do? How far has the project come.
> 
> Linux is already ported to SEGA Dreamcast by me, privately.  It
> can boot from CD-R and have supports for serial port, frame
> buffer, and pad/keyboard.  Someone might see that Niibe gave a
> demonstration at Linux Kongress 2000.
> 
> Currently it can run only on the restricted environment with
> initrd.  It can handle none of GD-ROM, Audio or Ethernet yet
> from lack of sepcs...  Yes, all the information I could get was
> from Marcus Comstedt's DC site.
> 

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

This is more than enough for us "hobbyists" to get started, other things
that could come later would be the expansion port (which gives us modem
and ethernet - eventually), better 3D support, etc.

> I'm sorry but I cannot release my port publicly, because I'm
> working for NAMCO, which has an NDA on Dreamcast with SEGA
> (actually I've not learned anything from SEGA under this NDA,
> but do they admit this fact?).  So I think I need SEGA's
> permission to release the port.

As far as kernel-specific (e.g. CONFIG_SH_DREAMCAST) stuff goes, do you
think you could release that?  I understand that you can't release
anything on the DC hardware, but could you give us some pointers on where
to get started on the actual port (e.g. how to structure devices, etc.).

> 
> 
> > First some DC / Linux questions:
> > 
> > Q1: Does someone have an ISO image to burn, or do you use the
> > serialslave to load the kernel from the DC?
> 
> I'm using GDB stub burned on CD-R to develop the kernel on
> Dremacast.
> 
>

Same here.  Still learning GDB though which is slowing me down a bit ;).
<leech> Do you have a .gdbinit you would recommend using? </leech>.
 
> > Q2: Is there an FB device that works with the PowerVR2 GFX. (As I
> > understand It the answer i NO)
> 
> Yes there is.  Framebuffer console is now working fine with
> SuperH Tux(many thanks to Greg:->).  We can login Dreamcast with
> keyboard or via serial port.
> 
>

I can't wait to get this working :)
 
> 
> Because Debian policy expects to be sh-linux-gcc(I heard gnu is
> reserved for Debian GNU/Hurd).  You can feel free to change the
> kernel's Makefile.
> 
> 
> > Q5: I have downloaded the kernel source from the CVS directory but fore
> > some reason it refuses to compile for GENERIC mode. Anyone who got a
> > clue why? Is it broken by default.
> 
> I cannot give any advice to you unless you tell me how it
> fails...
> 

It may be how the kernel include paths are setup, you have to make sure
that the kernel's includes are pointing to the sh-kernel directory and not
/usr/include or /usr/src/linux/include (if that's where your normal kernel
resides). 

> 
> > Q6: Are there any specific switches that should / shouldn't be used when
> > compiling the kernel to the DC. I thought of making a special "class"
> > fro the DC in the compiler script. Is this a good idea?
> 
> Agreed.  I've already added CONFIG_SH_DREAMCAST configuration to
> the kernel.
> 

Can you be more specific on this, without breaking NDA :)?

> 
> Any other comments, developers?
> 

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

Those who are interested in Dreamcast programming at all should check out
the dcdev mailinglist at http://www.egroups.com.  Also good places to
start for info are Marcus's (not me) site: http://mc.pp.se/dc/, and Dan's
site: http://www.allusion.net/dcdev/.

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

M. R. Brown

[linuxsh-dev] Fix timing loop

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

This is the accuracy fix I mentioned the other day.

Jesper

Index: ChangeLog
===================================================================
RCS file: /cvsroot/linuxsh/kernel/ChangeLog,v
retrieving revision 1.105
diff -u -5 -r1.105 ChangeLog
--- ChangeLog	2000/10/13 02:11:57	1.105
+++ ChangeLog	2000/10/26 09:01:55
@@ -1,5 +1,11 @@
+2000-10-26  Jesper Skov  <js...@re...>
+
+	David Woodhouse <dw...@re...>:
+	* arch/sh/kernel/time.c (get_cpu_mhz): Align loop to ensure
+	accuracy.
+
 2000-01-13  Greg Banks  <gb...@po...>
 
 	* arch/sh/config.in: HD64465 PCMCIA support.  These changes
 	needed for the PCMCIA host bridge driver currently submitted
 	to the PCMCIA maintainer.
Index: arch/sh/kernel/time.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/time.c,v
retrieving revision 1.16
diff -u -5 -r1.16 time.c
--- arch/sh/kernel/time.c	2000/09/30 03:43:30	1.16
+++ arch/sh/kernel/time.c	2000/10/26 09:01:57
@@ -335,10 +335,11 @@
 
 	sti();
 	do {} while (ctrl_inb(R64CNT) != 0);
 	ctrl_outb(RCR1_CIE, RCR1); /* Enable carry interrupt */
 	asm volatile(
+		".align2\n\t"
 		"1:\t"
 		"tst	%1,%1\n\t"
 		"bt/s	1b\n\t"
 		" add	#1,%0"
 		: "=r"(count), "=z" (__dummy)

Re: [linuxsh-dev] Re: LinuxSH4 linker problems

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

Mitch Davis wrote:
> 
> Adrian Stoica wrote:
> >
> > I had the same problem as Bryan, i.e. ld was bombing out when attempting to
> > link the kernel. It turned out that the problem was down to lines 7 - 10 in
> > arch/sh/vmlinux.lds.S specifying illegal formats:
> 
> > Replacing the above lines with:
> >
> > #ifdef CONFIG_CPU_LITTLE_ENDIAN
> > OUTPUT_FORMAT("elf32-shl", "elf32-shl", "elf32-shl")
> > #else
> > OUTPUT_FORMAT("elf32-sh", "elf32-sh", "elf32-sh")
> > #endif
> 
> Unless someone tells me otherwise, I'll be checking Adrian's change
> into the kernel CVS repository shortly.  Then we won't have both
> new and experienced people scratching their heads.  Broken is no fun.

I have now checked in Adrian's patch.

To whoever is planning to check in the toolchain changes - I would
suggest making the vmlinux.lds.S change in your CVS checkout, but
not checking it in until the time when you check the other toolchain
changes in as well.  That way we'll minimise the broken-state time.

Regards,

Mitch.

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

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

Thank you very mych for all the help.


YAEGASHI Takeshi wrote:

> 
> Currently it can run only on the restricted environment with
> initrd.  It can handle none of GD-ROM, Audio or Ethernet yet
> from lack of sepcs...  Yes, all the information I could get was
> from Marcus Comstedt's DC site.

Ok is information on these chips interesting to the development team?

> 
> 
> I'm sorry but I cannot release my port publicly, because I'm
> working for NAMCO, which has an NDA on Dreamcast with SEGA
> (actually I've not learned anything from SEGA under this NDA,
> but do they admit this fact?).  So I think I need SEGA's
> permission to release the port.


I see you got the same kind of support over there as we do in Europe 
;-). But seriosly, usualy NDAs only cover the things that they hand over 
to you, and since they havn't... But yours could be different, I only 
know how its done over here. But i don't want to get you in troubel with 
your boss.

> 
> 
>> Q2: Is there an FB device that works with the PowerVR2 GFX. (As I
>> understand It the answer i NO)
> 
> 
> Yes there is.  Framebuffer console is now working fine with
> SuperH Tux(many thanks to Greg:->).  We can login Dreamcast with
> keyboard or via serial port.

Ok so there is an FB for the DC. In what kernel and where do I find it. 
(Is it publicly availible?) I tried the 2.4.0-test9 and the CVS kernel 
from linux-sh but couldnt find FB support.

> 
> 
> 
>> Q3:  I have heard and seen an someone with an NIC (Network Interface
>> Card) but so far haven't had any luck in getting hold of one. Are they
>> available in Japan or US?
> 
> 
> I have one.  It can be ordered from SEGA's site(but in Japanese).
> 
> 	http://www3.csi-msp.com/dcweb/


Ok thet explains it. How do you get one to Europe? My Japanese is about 
as good as your Swedish ;-). Colud you buy me one (ill wiretransfer you 
the money in advance and you could send it to me via TNT or something 
like that.)

> 
> 
> 
>> Q4: I managed to download the x86 cross compile tools from
>> 
>> ftp://ftp.m17n.org/pub/linux-sh/debian/packages-i386/
>> 
>> but for some reason the tools are installed as sh-linux-gcc and not
>> sh-linux-gnu-gcc as the kernel expects, why?
> 
> 
> Because Debian policy expects to be sh-linux-gcc(I heard gnu is
> reserved for Debian GNU/Hurd).  You can feel free to change the
> kernel's Makefile.

Ok... Right now I took the easy way out (symlinks)

> 
> 
> 
>> Q5: I have downloaded the kernel source from the CVS directory but fore
>> some reason it refuses to compile for GENERIC mode. Anyone who got a
>> clue why? Is it broken by default.
> 
> 
> I cannot give any advice to you unless you tell me how it
> fails...


Right now I think its because I got an "old" kernel without FB support 
but tried to compile it in anyway. I'll wait for a new kernel.

> 
> 
> 
>> Q6: Are there any specific switches that should / shouldn't be used when
>> compiling the kernel to the DC. I thought of making a special "class"
>> fro the DC in the compiler script. Is this a good idea?
> 
> 
> Agreed.  I've already added CONFIG_SH_DREAMCAST configuration to
> the kernel.

Great, it make life a lot easyer for newbies.

>> Q8: How far has the Debian GNU/Linux Distribution come? As I understand
>> It its just n it infancy, and where is the help most needed?
> 
> 
> It depends on how long time it takes that GNU toolchain and
> glibc for SuperH get stable, I think.  Currently Niibe and kaz
> are working on it.  I really appreciate that.
> 
Ah the missing link, glibc. But arn't ther some .deb packeges on m17n ?
They moved to old last week. Is it becouse there is a larger upgrade 
going on?


/Rene

Re: [linuxsh-dev] Re: LinuxSH4 linker problems

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

Adrian Stoica wrote:
> 
> I had the same problem as Bryan, i.e. ld was bombing out when attempting to
> link the kernel. It turned out that the problem was down to lines 7 - 10 in
> arch/sh/vmlinux.lds.S specifying illegal formats:

> Replacing the above lines with:
> 
> #ifdef CONFIG_CPU_LITTLE_ENDIAN
> OUTPUT_FORMAT("elf32-shl", "elf32-shl", "elf32-shl")
> #else
> OUTPUT_FORMAT("elf32-sh", "elf32-sh", "elf32-sh")
> #endif
> 
> fixed the crash in my case.
> Hope this helps.

Immensely.

Guys, I understand we want to move to the format name of elf32-sh-linux,
but this situation of having a mismatch between the publicly available
versions of the kernel and binutils etc is crazy and has gone on for far
too long.

Unless someone tells me otherwise, I'll be checking Adrian's change
into the kernel CVS repository shortly.  Then we won't have both
new and experienced people scratching their heads.  Broken is no fun.

When the new tool chain is checked in, THEN we can change the Linux
linker script to match.

Regards,

Mitch.

PS: Thank you Adrian for sending in this patch.

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

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

Hello Rene,

In the article <39F...@li...>,
Rene Malmgren <re...@li...> wrote:

> Can someone please tell me what works and what doesn't yet, and how do
> you get it to do? How far has the project come.

Linux is already ported to SEGA Dreamcast by me, privately.  It
can boot from CD-R and have supports for serial port, frame
buffer, and pad/keyboard.  Someone might see that Niibe gave a
demonstration at Linux Kongress 2000.

Currently it can run only on the restricted environment with
initrd.  It can handle none of GD-ROM, Audio or Ethernet yet
from lack of sepcs...  Yes, all the information I could get was
from Marcus Comstedt's DC site.

I'm sorry but I cannot release my port publicly, because I'm
working for NAMCO, which has an NDA on Dreamcast with SEGA
(actually I've not learned anything from SEGA under this NDA,
but do they admit this fact?).  So I think I need SEGA's
permission to release the port.


> First some DC / Linux questions:
> 
> Q1: Does someone have an ISO image to burn, or do you use the
> serialslave to load the kernel from the DC?

I'm using GDB stub burned on CD-R to develop the kernel on
Dremacast.


> Q2: Is there an FB device that works with the PowerVR2 GFX. (As I
> understand It the answer i NO)

Yes there is.  Framebuffer console is now working fine with
SuperH Tux(many thanks to Greg:->).  We can login Dreamcast with
keyboard or via serial port.


> Q3:  I have heard and seen an someone with an NIC (Network Interface
> Card) but so far haven't had any luck in getting hold of one. Are they
> available in Japan or US?

I have one.  It can be ordered from SEGA's site(but in Japanese).

	http://www3.csi-msp.com/dcweb/


> Q4: I managed to download the x86 cross compile tools from
> 
> ftp://ftp.m17n.org/pub/linux-sh/debian/packages-i386/
> 
> but for some reason the tools are installed as sh-linux-gcc and not
> sh-linux-gnu-gcc as the kernel expects, why?

Because Debian policy expects to be sh-linux-gcc(I heard gnu is
reserved for Debian GNU/Hurd).  You can feel free to change the
kernel's Makefile.


> Q5: I have downloaded the kernel source from the CVS directory but fore
> some reason it refuses to compile for GENERIC mode. Anyone who got a
> clue why? Is it broken by default.

I cannot give any advice to you unless you tell me how it
fails...


> Q6: Are there any specific switches that should / shouldn't be used when
> compiling the kernel to the DC. I thought of making a special "class"
> fro the DC in the compiler script. Is this a good idea?

Agreed.  I've already added CONFIG_SH_DREAMCAST configuration to
the kernel.


> And then some more general SH-Linux questions:
> 
> Q7: What kind of development boards exist for this particular CPU and
> where can they be purchased. (Links would be fine, approximately price
> also)

I don't know well, hope somebody advise you...


> Q8: How far has the Debian GNU/Linux Distribution come? As I understand
> It its just n it infancy, and where is the help most needed?

It depends on how long time it takes that GNU toolchain and
glibc for SuperH get stable, I think.  Currently Niibe and kaz
are working on it.  I really appreciate that.


> Q9: Is there an .plan fore the platform

When new toolchain and glibc are available, we can start Debian
port again.

Any other comments, developers?

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

[linuxsh-dev] Debian GNU/Linux on Dreamcast

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

Hi everyone, I'm new here so please bare with my newbie questions.

My current pet project is to get my Dreamcast to run Linux and hopefully
become somewhat of an X terminal or perhaps even be able to run some
DIVX ;-) Cds. I have been looking for a good HOWTO on the project or
perhaps even an home page. Unfortunately I have only managed to get bits
and pieces. So I thought it might be a good idea to write my own HOWTO
on the subject. But I could use some help. As I understand it applets
two people on this list have bean able to boot the kernel on a DC. So I
would appreciate it if someone could help me out (so I won't make all of
your mistakes again) Here's my understanding of things, please correct
me if I'm wrong. The Dreamcast can boot Linux from a CDR. but there is
quite some "magic" involved in getting it done. Perhaps its over the
serial cable that Marcus has on his home page

http://mc.pp.se/dc/serifc.html
but so far there are no ISO images to be simply downloaded and burnt.
(If there aren't then I would like to help create some, but again all
help I can get would be much appreciated)

Can someone please tell me what works and what doesn't yet, and how do
you get it to do? How far has the project come.

First some DC / Linux questions:

Q1: Does someone have an ISO image to burn, or do you use the
serialslave to load the kernel from the DC?

Q2: Is there an FB device that works with the PowerVR2 GFX. (As I
understand It the answer i NO)

Q3:  I have heard and seen an someone with an NIC (Network Interface
Card) but so far haven't had any luck in getting hold of one. Are they
available in Japan or US?

Q4: I managed to download the x86 cross compile tools from

ftp://ftp.m17n.org/pub/linux-sh/debian/packages-i386/

but for some reason the tools are installed as sh-linux-gcc and not
sh-linux-gnu-gcc as the kernel expects, why?

Q5: I have downloaded the kernel source from the CVS directory but fore
some reason it refuses to compile for GENERIC mode. Anyone who got a
clue why? Is it broken by default.

Q6: Are there any specific switches that should / shouldn't be used when
compiling the kernel to the DC. I thought of making a special "class"
fro the DC in the compiler script. Is this a good idea?

And then some more general SH-Linux questions:

Q7: What kind of development boards exist for this particular CPU and
where can they be purchased. (Links would be fine, approximately price
also)

Q8: How far has the Debian GNU/Linux Distribution come? As I understand
It its just n it infancy, and where is the help most needed?

Q9: Is there an .plan fore the platform


/Rene

[linuxsh-dev] Linuxsh + Nano-X

[Mauro G. <gus...@ho...>]

Hello linuxsh-dev

About graphic
What do you think about the use of Nano-X? (a X11 like windowing system for 
embedded system, it uses a framebuffer mechanism to work with graphic 
hardware)
http://www.microwindows.org
Anybody is testing this way?

Now it's possible to use and test a Nano-X browser: NanoZilla (from Mozilla 
I think)
http://www.igelaus.com.au/projects/nanox.html

Thanks
Mauro
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

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

Hi all,
Ouch, there was mistake, please ignore bogus mail from me...

In the article <ota...@th...>,
Jesper Skov <js...@re...> wrote:

> >>>>> "ebihara" == ebihara  <ebi...@si...> writes:
> 
> ebihara> hello all.  time.c didn't work well for detecting busclock
> ebihara> and moduleclock.  so i made a patch for 'time.c'. (sh3 only)
> 
> This is the wrong approach. Well, it may work for your board, but may
> mess up other boards.
> 
> I've just done a rewrite of the clock setup configuration in eCos,
> supporting 7707, 7708, 7709A and 7729. And let me tell you, it's
> seriously non-trivial to get right. And I have the benefit of being
> able to rely on a compile time configuration to get it right.

Long ago I wrote a patch for this issue for Linux/SH and post to
SourceForge.  But unfortunately it has been forgotten by people
and not yet incorporated with the kernel. :->

For your reference:
	http://www.geocrawler.com/archives/3/3076/2000/6/0/3870573/


> IMO it's a serious mistake that the CPUs don't include a version
> register of some sort so they can be properly identified at runtime
> [does anybody know of a non-documented version register, by any
> chance?]. Add to that some way to figure out which clock mode the CPU
> is configured to use, and it would actually be possible to compute all
> the magic at run time.

Agreed.


> As it is, the clock setup code in Linux needs a very careful
> rewrite. And no, I'm not volunteering just now :) Some rainy Sunday,
> maybe.
> 
> 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.

The newer is the better.  I look forward to your path.

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

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

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

Hi all,

In the article <ota...@th...>,
Jesper Skov <js...@re...> wrote:

> >>>>> "ebihara" == ebihara  <ebi...@si...> writes:
> 
> ebihara> hello all.  time.c didn't work well for detecting busclock
> ebihara> and moduleclock.  so i made a patch for 'time.c'. (sh3 only)
> 
> This is the wrong approach. Well, it may work for your board, but may
> mess up other boards.
> 
> I've just done a rewrite of the clock setup configuration in eCos,
> supporting 7707, 7708, 7709A and 7729. And let me tell you, it's
> seriously non-trivial to get right. And I have the benefit of being
> able to rely on a compile time configuration to get it right.

Long ago I wrote a patch for this issue for Linux/SH and post to
SourceForge.  But unfortunately it has been forgotten by people
and not yet incorporated with the kernel. :->

For your reference:
	http://www.geocrawler.com/archives/3/3076/2000/6/0/3870573/


> IMO it's a serious mistake that the CPUs don't include a version
> register of some sort so they can be properly identified at runtime
> [does anybody know of a non-documented version register, by any
> chance?]. Add to that some way to figure out which clock mode the CPU
> is configured to use, and it would actually be possible to compute all
> the magic at run time.

Agreed.


> As it is, the clock setup code in Linux needs a very careful
> rewrite. And no, I'm not volunteering just now :) Some rainy Sunday,
> maybe.
> 
> 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.

The newer is the better.  I look forward to your path.

--
八重樫 剛史 <yae...@rd...>

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

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

>>>>> "ebihara" == ebihara  <ebi...@si...> writes:

ebihara> hello all.  time.c didn't work well for detecting busclock
ebihara> and moduleclock.  so i made a patch for 'time.c'. (sh3 only)

This is the wrong approach. Well, it may work for your board, but may
mess up other boards.

I've just done a rewrite of the clock setup configuration in eCos,
supporting 7707, 7708, 7709A and 7729. And let me tell you, it's
seriously non-trivial to get right. And I have the benefit of being
able to rely on a compile time configuration to get it right.

IMO it's a serious mistake that the CPUs don't include a version
register of some sort so they can be properly identified at runtime
[does anybody know of a non-documented version register, by any
chance?]. Add to that some way to figure out which clock mode the CPU
is configured to use, and it would actually be possible to compute all
the magic at run time.

As it is, the clock setup code in Linux needs a very careful
rewrite. And no, I'm not volunteering just now :) Some rainy Sunday,
maybe.

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.

Jesper

Re: [linuxsh-dev] CVS problem

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

Jaswinder Singh wrote:
> 
> On this saturday when i met him , i also asked about
> you :-)

Oh, so now you know what it sounds like when people swear in
Japanese! :-)

> Is there any way that i can get tar file of this kernel

Try visiting this page, then saving the link it points to.

  http://linuxsh.sourceforge.net/kernel-20001016.html

(You'll need to do an explicit "save-as", as apparently Apache
at SourceForge doesn't understand it's a binary file - it comes
up as text).

BTW I put that tree there because you asked for files.  If I had
known you wanted the whole archive, I'd have put it there in
the beginning.

> from your site.

It's not my site, it's our site.  Yours as well as mine.  Have
you a SourceForge developer ID yet?

Regards,

Mitch.

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

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

Bryan Rittmeyer wrote:
> 
> Hello NIIBE-san and linuxsh-dev,
> 
> Also, in the latest CVS sh_ksyms.c I had to comment out
> "EXPORT_SYMBOL(dispatch_virtual_irq);" to get the file to build. I think
> this is related to Greg's PCMCIA changes and will eventually go away on
> its own, so I did not include that change in the above sh_ksyms.c
> patch...

  Yep, sorry about that. It just went away.


Greg.
-- 
These are my opinions not PPIs.

Re: [linuxsh-dev] CVS problem

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

Dear Mitch,

--- Mitch Davis <md...@po...> wrote:
> 
> Yeah, Niibe-san's great value.  I hope we can meet
> again soon.
>

yes , you are right .

On this saturday when i met him , i also asked about
you :-)

> 
> At great expense to the SourceForge management (and
> their
> disk space!) I've checked out a copy of the latest
> kernel
> you can cruise with your web browser.  I will be
> removing it
> when SourceForge fix the CVSweb problem, so don't
> bookmark it!
> 
>   http://linuxsh.sourceforge.net/kernel/
> 
> Hope this helps get you out of your sticky
> situation.
> 

Thank you very much . 
Is there any way that i can get tar file of this
kernel from your site.

Thanks,

Best Regards,

Jaswinder.

 
> Regards,
> 
> Mitch.


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

Re: [linuxsh-dev] CVS problem

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

Jaswinder Singh wrote:
> 
> Now a days , i am in Japan and i am really enjoying my
> trip because Niibe-san are helping me alot :-)

Yeah, Niibe-san's great value.  I hope we can meet again soon.

> I just want to see some files which Niibe-san
> suggested me . I am trying it from friday . Is there
> any way to see that files or can you send me some
> files , if i give you the name of that files .

At great expense to the SourceForge management (and their
disk space!) I've checked out a copy of the latest kernel
you can cruise with your web browser.  I will be removing it
when SourceForge fix the CVSweb problem, so don't bookmark it!

  http://linuxsh.sourceforge.net/kernel/

Hope this helps get you out of your sticky situation.

Regards,

Mitch.

Re: [linuxsh-dev] CVS problem

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

Dear Mitch ,

Now a days , i am in Japan and i am really enjoying my
trip because Niibe-san are helping me alot :-)

I just want to see some files which Niibe-san
suggested me . I am trying it from friday . Is there
any way to see that files or can you send me some
files , if i give you the name of that files . 

thanks .

Best Regards,

Jaswinder.



--- Mitch Davis <md...@po...> wrote:
> 
> Hi Jaswinder,
> 
> I see what you mean!  It's currently not possible to
> view the contents
> of a file using CVSweb...
> 
> I have reported it to the SourceForge people and I
> hope they
> will resolve it soon.
> 
>  
>
https://sourceforge.net/support/?func=detailsupport&support_id=106673&group_id=1
> 
> Regards,
> 
> Mitch.
> _______________________________________________


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

Re: [linuxsh-dev] CVS problem

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

Jaswinder Singh wrote:
> 
> Dear Mitch and Greg ,
> 
> i am not able to access kernel sources from CVS . i
> want to see few files . but i am getting this error
> from 2 days :-
> 
> Error
> Error: Unexpected output from cvs co: cvs checkout:
> Sorry, you don't have read/write access to the history
> file cvs [checkout aborted]:
> /cvsroot/linuxsh/CVSROOT/history: Permission denied
> Check whether the directory /cvsroot/linuxsh/CVSROOT
> exists and the script has write-access to the
> CVSROOT/history file if it exists.
> The script needs to place lock files in the directory
> the file is in as well.
>
> Created by a SourceForge version of CVSweb.

Hi Jaswinder,

I see what you mean!  It's currently not possible to view the contents
of a file using CVSweb...

I have reported it to the SourceForge people and I hope they
will resolve it soon.

  https://sourceforge.net/support/?func=detailsupport&support_id=106673&group_id=1

Regards,

Mitch.

Re: [linuxsh-dev] CVS problem

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

hi linuxsh-dev group,

Oops i am still getting this error . 

Can somebody help me . Is problem is from my side or
from sourceforge.

Thank you very much .

Best Regards,

Jaswinder.


--- Jaswinder Singh <jas...@ya...> wrote:
> Dear Mitch and Greg ,
> 
> i am not able to access kernel sources from CVS . i
> want to see few files . but i am getting this error
> from 2 days :-
> 
> Error
> Error: Unexpected output from cvs co: cvs checkout:
> Sorry, you don't have read/write access to the
> history
> file cvs [checkout aborted]:
> /cvsroot/linuxsh/CVSROOT/history: Permission denied 
> Check whether the directory /cvsroot/linuxsh/CVSROOT
> exists and the script has write-access to the
> CVSROOT/history file if it exists.
> The script needs to place lock files in the
> directory
> the file is in as well. 
> 
> 
>
--------------------------------------------------------------------------------
> Created by a SourceForge version of CVSweb. 
> 
> thanks .
> 
> Best Regards ,
> 
> Jaswinder.
> 


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

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

[Bryan R. <br...@ix...>]

Hello NIIBE-san and linuxsh-dev,

When trying to build the latest CVS kernel with a machine type of
"BareCPU" the build fails on setup.c:

sh-linux-gnu-gcc -D__KERNEL__ -I/home/bryan/src/sh/kernel/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -ml -m4 -pipe
-fno-strict-aliasing    -c -o setup.o setup.c
setup.c: In function `setup_arch':
setup.c:311: `mv_unknown' undeclared (first use in this function)
setup.c:311: (Each undeclared identifier is reported only once
setup.c:311: for each function it appears in.)
make[1]: *** [setup.o] Error 1

This error is because there is no extern declaration for mv_unknown when
building with CONFIG_SH_UNKNOWN. Here's my patch, which I believe is
correct:

--- arch/sh/kernel/setup-old.c  Sat Oct 14 14:03:08 2000
+++ arch/sh/kernel/setup.c      Sat Oct 14 13:54:40 2000
@@ -269,6 +269,10 @@
        int mv_mmio_enable = 0;
        unsigned long bootmap_size;
        unsigned long start_pfn, max_pfn, max_low_pfn;
+       
+#ifdef CONFIG_SH_UNKNOWN
+       extern struct sh_machine_vector mv_unknown;
+#endif
 
 #ifdef CONFIG_SH_EARLY_PRINTK
        sh_console_init();

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

--- sh_ksyms-old.c      Sat Oct 14 14:03:08 2000
+++ sh_ksyms.c  Sat Oct 14 14:12:54 2000
@@ -49,7 +49,7 @@
 EXPORT_SYMBOL(memset);
 EXPORT_SYMBOL(memmove);
 
-/* this is not provided by arch/sh/lib/*.S but is
+/* this is not provided by arch/sh/lib/mem*.S but is
    potentially needed by modules (af_packet.o/unix.o
    use memcmp, for instance) */
 EXPORT_SYMBOL(memcmp);

Also, in the latest CVS sh_ksyms.c I had to comment out
"EXPORT_SYMBOL(dispatch_virtual_irq);" to get the file to build. I think
this is related to Greg's PCMCIA changes and will eventually go away on
its own, so I did not include that change in the above sh_ksyms.c
patch...

Regards,

Bryan

-- 
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302

Re: [linuxsh-dev] Re: LinuxSH4 linker problems

[Bryan R. <br...@ix...>]

Adrian Stoica wrote:
 
> Hi,
> 
> I had the same problem as Bryan, i.e. ld was bombing out when attempting to
> link the kernel. It turned out that the problem was down to lines 7 - 10 in
> arch/sh/vmlinux.lds.S specifying illegal formats:
> 
> #ifdef CONFIG_CPU_LITTLE_ENDIAN
> OUTPUT_FORMAT("elf32-sh-linux", "elf32-sh-linux", "elf32-sh-linux")
> #else
> OUTPUT_FORMAT("elf32-shbig-linux", "elf32-shbig-linux", "elf32-shbig-linux")
> 
> Running sh-linux-gnu-objdump gives: "supported targets: elf32-sh elf32-shl
> coff-sh coff-shl coff-sh-small coff-shl-small elf32-little elf32-big srec
> symbolsrec tekhex binary ihex", there is no "elf32-sh-linux", etc.
> 
> Replacing the above lines with:
> 
> #ifdef CONFIG_CPU_LITTLE_ENDIAN
> OUTPUT_FORMAT("elf32-shl", "elf32-shl", "elf32-shl")
> #else
> OUTPUT_FORMAT("elf32-sh", "elf32-sh", "elf32-sh")
> #endif
> 
> fixed the crash in my case.

Hm. I also traced the problem down to vmlinux.lds.S and copied an older
version I had from a 2.4.0-test8 CVS checkout into the newer kernel
directory... that seemed to fix it.

Perhaps these changes to vmlinux.lds.S should have waited until the new
toolchain is availible?!

Regards,

Bryan

-- 
Bryan Rittmeyer
mailto:br...@ix...
Ixia Communications
26601 W. Agoura Rd.
Calabasas, CA 91302

[linuxsh-dev] CVS problem

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

Dear Mitch and Greg ,

i am not able to access kernel sources from CVS . i
want to see few files . but i am getting this error
from 2 days :-

Error
Error: Unexpected output from cvs co: cvs checkout:
Sorry, you don't have read/write access to the history
file cvs [checkout aborted]:
/cvsroot/linuxsh/CVSROOT/history: Permission denied 
Check whether the directory /cvsroot/linuxsh/CVSROOT
exists and the script has write-access to the
CVSROOT/history file if it exists.
The script needs to place lock files in the directory
the file is in as well. 


--------------------------------------------------------------------------------
Created by a SourceForge version of CVSweb. 

thanks .

Best Regards ,

Jaswinder.




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

[linuxsh-dev] Re: LinuxSH4 linker problems

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

Hi,

I had the same problem as Bryan, i.e. ld was bombing out when attempting to
link the kernel. It turned out that the problem was down to lines 7 - 10 in
arch/sh/vmlinux.lds.S specifying illegal formats:

#ifdef CONFIG_CPU_LITTLE_ENDIAN
OUTPUT_FORMAT("elf32-sh-linux", "elf32-sh-linux", "elf32-sh-linux")
#else
OUTPUT_FORMAT("elf32-shbig-linux", "elf32-shbig-linux", "elf32-shbig-linux")

Running sh-linux-gnu-objdump gives: "supported targets: elf32-sh elf32-shl
coff-sh coff-shl coff-sh-small coff-shl-small elf32-little elf32-big srec
symbolsrec tekhex binary ihex", there is no "elf32-sh-linux", etc.

Replacing the above lines with:

#ifdef CONFIG_CPU_LITTLE_ENDIAN
OUTPUT_FORMAT("elf32-shl", "elf32-shl", "elf32-shl")
#else
OUTPUT_FORMAT("elf32-sh", "elf32-sh", "elf32-sh")
#endif

fixed the crash in my case.
Hope this helps.


Adrian

Re: [linuxsh-dev] PCMCIA patch & question

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

Have tested on SolutionEngine.  More changes are needed to save PR register
in call_dpf in entry.S.

Greg Banks wrote:
 >    Is _PAGE_HW_SHARED right for kernel-only mappings?  I'm not sure
 > of the implications...

This is needed because we share the kernel mapping.  SuperH's MMU SH-bit
means that it doesn't look ASID on TLB comparison, when it is 1.

With old implementation, all the processes have PGD table entries for
kernel mapping, and we keep the kernel mapping entries same with
set_pgdir.  However, as SuperH has SH-bit, it's a kind of waste of 
memory and CPU cycles.
-- 

Re: [linuxsh-dev] PCMCIA patch & question

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

NIIBE Yutaka wrote:
> 
> NIIBE Yutaka wrote:
>  > I'll do the changes of optimizing PGD and removing set_pgdir for SuperH.
> 
> Done.

  Looks good, as far as I can understand it ;-)  Except for ....

> 
> ===================================================================
> RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/ioremap.c,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 ioremap.c
> --- arch/sh/mm/ioremap.c        2000/04/14 16:49:01     1.1.1.1
> +++ arch/sh/mm/ioremap.c        2000/10/13 02:14:17
> @@ -17,6 +17,9 @@ static inline void remap_area_pte(pte_t
>         unsigned long phys_addr, unsigned long flags)
>  {
>         unsigned long end;
> +       pgprot_t pgprot = __pgprot(_PAGE_PRESENT | _PAGE_RW |
> +                                  _PAGE_DIRTY | _PAGE_ACCESSED |
> +                                  _PAGE_HW_SHARED | _PAGE_FLAGS_HARD | flags);

   Is _PAGE_HW_SHARED right for kernel-only mappings?  I'm not sure
of the implications...

Greg.
-- 
These are my opinions not PPIs.

[linuxsh-dev] PCMCIA patch & question

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

NIIBE Yutaka wrote:
 > I'll do the changes of optimizing PGD and removing set_pgdir for SuperH.

Done.

When I'll import changes in test10-pre2, I'll commit this change.

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

	* arch/sh/mm/fault.c (__do_page_fault): Removed (now it's call_dpf
	in entry.S).
	(__do_page_fault): Rename from __do_page_fault1.

	* arch/sh/kernel/entry.S (call_dpf): New entry.
	(tlb_miss_load, tlb_miss_store, initial_page_write,
	tlb_protection_violation_load, tlb_protection_violation_store): Use
	call_dpf.

	* include/asm-sh/pgalloc-2level.h (get_pmd_fast, free_pmd_fast,
	free_pmd_slow, pmd_alloc): Make them static inline.

	* arch/sh/mm/ioremap.c (remap_area_pages): Use pgd_offset_k.
	(remap_area_pte): Use _PAGE_HW_SHARED.
	(remap_area_pages): Remove set_pgdir.

	* include/asm-sh/pgalloc.h (set_pgdir): Removed.
	(get_pgd_slow, get_pgd_fast, free_pgd_fast, free_pgd_slow, 
	get_pte_fast, free_pte_fast, free_pte_slow, pte_alloc_kernel, 
	pte_alloc, pmd_free, flush_tlb_pgtables): Make them static inline.
	(get_pgd_slow, free_pgd_slow): Use 2KB PGD.

Index: arch/sh/kernel/entry.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/entry.S,v
retrieving revision 1.26
diff -u -p -r1.26 entry.S
--- arch/sh/kernel/entry.S	2000/09/30 03:43:30	1.26
+++ arch/sh/kernel/entry.S	2000/10/13 02:14:16
@@ -149,52 +149,55 @@ SYSCALL_NR =  (16*4+6*4)
 
 	.align	2
 tlb_miss_load:
-	mov.l	2f, $r0
-	mov.l	@$r0, $r6
-	mov	$r15, $r4
-	mov.l	1f, $r0
-	jmp	@$r0
+	bra	call_dpf
 	 mov	#0, $r5
 
 	.align	2
 tlb_miss_store:
-	mov.l	2f, $r0
-	mov.l	@$r0, $r6
-	mov	$r15, $r4
-	mov.l	1f, $r0
-	jmp	@$r0
+	bra	call_dpf
 	 mov	#1, $r5
 
 	.align	2
 initial_page_write:
-	mov.l	2f, $r0
-	mov.l	@$r0, $r6
-	mov	$r15, $r4
-	mov.l	1f, $r0
-	jmp	@$r0
+	bra	call_dpf
 	 mov	#1, $r5
 
 	.align	2
 tlb_protection_violation_load:
-	mov.l	2f, $r0
-	mov.l	@$r0, $r6
-	mov	$r15, $r4
-	mov.l	1f, $r0
-	jmp	@$r0
+	bra	call_dpf
 	 mov	#0, $r5
 
 	.align	2
 tlb_protection_violation_store:
-	mov.l	2f, $r0
-	mov.l	@$r0, $r6
-	mov	$r15, $r4
+	bra	call_dpf
+	 mov	#1, $r5
+
+call_dpf:
 	mov.l	1f, $r0
+	mov.l	@$r0, $r6
+	! r4, r5 and r6 may be clobbered
+	mov	$r6, $r9
+	mov	$r5, $r8
+	!
+	mov.l	2f, $r0
+	jsr	@$r0
+	 mov	$r15, $r4
+	!
+	cmp/eq	#0, $r0
+	bf	0f
+	rts
+	 nop
+0:	STI()
+	mov.l	3f, $r0
+	mov	$r9, $r6
+	mov	$r8, $r5
 	jmp	@$r0
-	 mov	#1, $r5
+	 mov	$r15, $r4
 
 	.align 2
-1:	.long	SYMBOL_NAME(__do_page_fault)
-2:	.long	MMU_TEA
+1:	.long	MMU_TEA
+2:	.long	SYMBOL_NAME(__do_page_fault)
+3:	.long	SYMBOL_NAME(do_page_fault)
 
 #if defined(CONFIG_DEBUG_KERNEL_WITH_GDB_STUB) || defined(CONFIG_SH_STANDARD_BIOS)
 	.align	2
Index: arch/sh/mm/fault.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/fault.c,v
retrieving revision 1.21
diff -u -p -r1.21 fault.c
--- arch/sh/mm/fault.c	2000/09/03 03:40:12	1.21
+++ arch/sh/mm/fault.c	2000/10/13 02:14:17
@@ -231,7 +231,10 @@ do_sigbus:
 		goto no_context;
 }
 
-static int __do_page_fault1(struct pt_regs *regs, unsigned long writeaccess,
+/*
+ * Called with interrupt disabled.
+ */
+asmlinkage int __do_page_fault(struct pt_regs *regs, unsigned long writeaccess,
 			    unsigned long address)
 {
 	pgd_t *dir;
@@ -240,8 +243,6 @@ static int __do_page_fault1(struct pt_re
 	pte_t entry;
 
 	if (address >= VMALLOC_START && address < VMALLOC_END)
-		/* We can change the implementation of P3 area pte entries.
-		   set_pgdir and such. */
 		dir = pgd_offset_k(address);
 	else
 		dir = pgd_offset(current->mm, address);
@@ -273,23 +274,6 @@ static int __do_page_fault1(struct pt_re
 	set_pte(pte, entry);
 	update_mmu_cache(NULL, address, entry);
 	return 0;
-}
-
-/*
- * Called with interrupt disabled.
- */
-asmlinkage void __do_page_fault(struct pt_regs *regs, unsigned long writeaccess,
-				unsigned long address)
-{
-	/*
-	 * XXX: Could you please implement this (calling __do_page_fault1)
-	 * in assembler language in entry.S?
-	 */
-	if (__do_page_fault1(regs, writeaccess, address)  == 0)
-		/* Done. */
-		return;
-	sti();
-	do_page_fault(regs, writeaccess, address);
 }
 
 void update_mmu_cache(struct vm_area_struct * vma,
Index: arch/sh/mm/ioremap.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/ioremap.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ioremap.c
--- arch/sh/mm/ioremap.c	2000/04/14 16:49:01	1.1.1.1
+++ arch/sh/mm/ioremap.c	2000/10/13 02:14:17
@@ -17,6 +17,9 @@ static inline void remap_area_pte(pte_t 
 	unsigned long phys_addr, unsigned long flags)
 {
 	unsigned long end;
+	pgprot_t pgprot = __pgprot(_PAGE_PRESENT | _PAGE_RW |
+				   _PAGE_DIRTY | _PAGE_ACCESSED |
+				   _PAGE_HW_SHARED | _PAGE_FLAGS_HARD | flags);
 
 	address &= ~PMD_MASK;
 	end = address + size;
@@ -25,8 +28,7 @@ static inline void remap_area_pte(pte_t 
 	do {
 		if (!pte_none(*pte))
 			printk("remap_area_pte: page already exists\n");
-		set_pte(pte, mk_pte_phys(phys_addr, __pgprot(_PAGE_PRESENT | _PAGE_RW | 
-					_PAGE_DIRTY | _PAGE_ACCESSED | flags)));
+		set_pte(pte, mk_pte_phys(phys_addr, pgprot));
 		address += PAGE_SIZE;
 		phys_addr += PAGE_SIZE;
 		pte++;
@@ -55,22 +57,21 @@ static inline int remap_area_pmd(pmd_t *
 }
 
 static int remap_area_pages(unsigned long address, unsigned long phys_addr,
-				 unsigned long size, unsigned long flags)
+	unsigned long size, unsigned long flags)
 {
 	pgd_t * dir;
 	unsigned long end = address + size;
 
 	phys_addr -= address;
-	dir = pgd_offset(&init_mm, address);
+	dir = pgd_offset_k(address);
 	flush_cache_all();
 	while (address < end) {
 		pmd_t *pmd = pmd_alloc_kernel(dir, address);
 		if (!pmd)
 			return -ENOMEM;
 		if (remap_area_pmd(pmd, address, end - address,
-					 phys_addr + address, flags))
+					phys_addr + address, flags))
 			return -ENOMEM;
-		set_pgdir(address, *dir);
 		address = (address + PGDIR_SIZE) & PGDIR_MASK;
 		dir++;
 	}
Index: include/asm-sh/pgalloc-2level.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgalloc-2level.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 pgalloc-2level.h
--- include/asm-sh/pgalloc-2level.h	2000/04/14 16:48:21	1.1.1.1
+++ include/asm-sh/pgalloc-2level.h	2000/10/13 02:14:18
@@ -5,15 +5,15 @@
  * traditional two-level paging, page table allocation routines:
  */
 
-extern __inline__ pmd_t *get_pmd_fast(void)
+static __inline__ pmd_t *get_pmd_fast(void)
 {
 	return (pmd_t *)0;
 }
 
-extern __inline__ void free_pmd_fast(pmd_t *pmd) { }
-extern __inline__ void free_pmd_slow(pmd_t *pmd) { }
+static __inline__ void free_pmd_fast(pmd_t *pmd) { }
+static __inline__ void free_pmd_slow(pmd_t *pmd) { }
 
-extern inline pmd_t * pmd_alloc(pgd_t *pgd, unsigned long address)
+static __inline__ pmd_t * pmd_alloc(pgd_t *pgd, unsigned long address)
 {
 	if (!pgd)
 		BUG();
Index: include/asm-sh/pgalloc.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgalloc.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 pgalloc.h
--- include/asm-sh/pgalloc.h	2000/04/14 16:48:21	1.1.1.1
+++ include/asm-sh/pgalloc.h	2000/10/13 02:14:18
@@ -17,18 +17,18 @@
  * if any.
  */
 
-extern __inline__ pgd_t *get_pgd_slow(void)
+static __inline__ pgd_t *get_pgd_slow(void)
 {
-	pgd_t *ret = (pgd_t *)__get_free_page(GFP_KERNEL);
+	unsigned int pgd_size = (USER_PTRS_PER_PGD * sizeof(pgd_t));
+	pgd_t *ret = (pgd_t *)kmalloc(pgd_size, GFP_KERNEL);
 
-	if (ret) {
-		memset(ret, 0, USER_PTRS_PER_PGD * sizeof(pgd_t));
-		memcpy(ret + USER_PTRS_PER_PGD, swapper_pg_dir + USER_PTRS_PER_PGD, (PTRS_PER_PGD - USER_PTRS_PER_PGD) * sizeof(pgd_t));
-	}
+	if (ret)
+		memset(ret, 0, pgd_size);
+
 	return ret;
 }
 
-extern __inline__ pgd_t *get_pgd_fast(void)
+static __inline__ pgd_t *get_pgd_fast(void)
 {
 	unsigned long *ret;
 
@@ -41,22 +41,22 @@ extern __inline__ pgd_t *get_pgd_fast(vo
 	return (pgd_t *)ret;
 }
 
-extern __inline__ void free_pgd_fast(pgd_t *pgd)
+static __inline__ void free_pgd_fast(pgd_t *pgd)
 {
 	*(unsigned long *)pgd = (unsigned long) pgd_quicklist;
 	pgd_quicklist = (unsigned long *) pgd;
 	pgtable_cache_size++;
 }
 
-extern __inline__ void free_pgd_slow(pgd_t *pgd)
+static __inline__ void free_pgd_slow(pgd_t *pgd)
 {
-	free_page((unsigned long)pgd);
+	kfree(pgd);
 }
 
 extern pte_t *get_pte_slow(pmd_t *pmd, unsigned long address_preadjusted);
 extern pte_t *get_pte_kernel_slow(pmd_t *pmd, unsigned long address_preadjusted);
 
-extern __inline__ pte_t *get_pte_fast(void)
+static __inline__ pte_t *get_pte_fast(void)
 {
 	unsigned long *ret;
 
@@ -68,14 +68,14 @@ extern __inline__ pte_t *get_pte_fast(vo
 	return (pte_t *)ret;
 }
 
-extern __inline__ void free_pte_fast(pte_t *pte)
+static __inline__ void free_pte_fast(pte_t *pte)
 {
 	*(unsigned long *)pte = (unsigned long) pte_quicklist;
 	pte_quicklist = (unsigned long *) pte;
 	pgtable_cache_size++;
 }
 
-extern __inline__ void free_pte_slow(pte_t *pte)
+static __inline__ void free_pte_slow(pte_t *pte)
 {
 	free_page((unsigned long)pte);
 }
@@ -85,7 +85,7 @@ extern __inline__ void free_pte_slow(pte
 #define pgd_free(pgd)	   free_pgd_slow(pgd)
 #define pgd_alloc()	     get_pgd_fast()
 
-extern inline pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
+static __inline__ pte_t * pte_alloc_kernel(pmd_t * pmd, unsigned long address)
 {
 	if (!pmd)
 		BUG();
@@ -105,7 +105,7 @@ extern inline pte_t * pte_alloc_kernel(p
 	return (pte_t *) pmd_page(*pmd) + address;
 }
 
-extern inline pte_t * pte_alloc(pmd_t * pmd, unsigned long address)
+static __inline__ pte_t * pte_alloc(pmd_t * pmd, unsigned long address)
 {
 	address = (address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
 
@@ -132,7 +132,7 @@ fix:
  * allocating and freeing a pmd is trivial: the 1-entry pmd is
  * inside the pgd, so has no extra memory associated with it.
  */
-extern inline void pmd_free(pmd_t * pmd)
+static __inline__ void pmd_free(pmd_t * pmd)
 {
 }
 
@@ -141,22 +141,6 @@ extern inline void pmd_free(pmd_t * pmd)
 
 extern int do_check_pgt_cache(int, int);
 
-extern inline void set_pgdir(unsigned long address, pgd_t entry)
-{
-	struct task_struct * p;
-	pgd_t *pgd;
-
-	read_lock(&tasklist_lock);
-	for_each_task(p) {
-		if (!p->mm)
-			continue;
-		*pgd_offset(p->mm,address) = entry;
-	}
-	read_unlock(&tasklist_lock);
-	for (pgd = (pgd_t *)pgd_quicklist; pgd; pgd = (pgd_t *)*(unsigned long *)pgd)
-		pgd[address >> PGDIR_SHIFT] = entry;
-}
-
 /*
  * TLB flushing:
  *
@@ -174,8 +158,9 @@ extern void flush_tlb_mm(struct mm_struc
 extern void flush_tlb_range(struct mm_struct *mm, unsigned long start,
 			    unsigned long end);
 extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long page);
-extern inline void flush_tlb_pgtables(struct mm_struct *mm,
-				      unsigned long start, unsigned long end)
+
+static __inline__ void flush_tlb_pgtables(struct mm_struct *mm,
+					  unsigned long start, unsigned long end)
 {
 }