Virtual address to physical address mapping...

Virtual address to physical address mapping...

[machael thailer]

Hello,

   I am a newbie on linux-mips. I read the linux-mips sources codes and
cannot  find where it builds the page tables (from Virtual address to
physical address mapping).
Can you point it out to me where I can find it?

Thank you very much.

machael thailer

Virtual address to physical address mapping...

[machael thailer]

Hello,

   I am a newbie on linux-mips. I read the linux-mips sources codes and
cannot  find where it builds the page tables (from Virtual address to
physical address mapping).
Can you point it out to me where I can find it?

Thank you very much.

machael thailer

Re: Virtual address to physical address mapping...

[Ralf Baechle]

On Wed, Aug 15, 2001 at 09:30:34AM +0800, machael thailer wrote:

>    I am a newbie on linux-mips. I read the linux-mips sources codes and
> cannot  find where it builds the page tables (from Virtual address to
> physical address mapping).
> Can you point it out to me where I can find it?

It only comes in the commercial edition ;-)

Checkout the mm/ directory which contains most of the generic code.
include/asm-mips/pgtable.h and arch/mips/mm/ contain most of the
MIPS specific code.

  Ralf

questions about eret....

[machael thailer]

Hello,all:

    I have a question to ask about eret.

    In RC4xxx/RC32334, after eret finished, does it automatically enable IE
bit of STATUS register?

Machael thailer

questions about eret....

[machael thailer]

Hello,all:

    I have a question to ask about eret.

    In RC4xxx/RC32334, after eret finished, does it automatically enable IE
bit of STATUS register?

Machael thailer

Re: questions about eret....

[Ralf Baechle]

On Mon, Aug 20, 2001 at 05:54:09PM +0800, machael thailer wrote:

>     I have a question to ask about eret.
> 
>     In RC4xxx/RC32334, after eret finished, does it automatically enable IE
> bit of STATUS register?

ERET does not influence the state of the IE bit.

  Ralf

Re: questions about eret....

[machael thailer]

----- Original Message -----
From: "Ralf Baechle" <ralf@oss.sgi.com>
To: "machael thailer" <dony.he@huawei.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 21, 2001 5:07 AM
Subject: Re: questions about eret....


> On Mon, Aug 20, 2001 at 05:54:09PM +0800, machael thailer wrote:
>
> >     I have a question to ask about eret.
> >
> >     In RC4xxx/RC32334, after eret finished, does it automatically enable
IE
> > bit of STATUS register?
>
> ERET does not influence the state of the IE bit.

I agree with you, but the RC32334 User manual (14-13 section) say  it does
and say we must run a "CLI" just before eret to disable IE bit in Status
register .

machael thailer

Re: questions about eret....

[machael thailer]

----- Original Message -----
From: "Ralf Baechle" <ralf@oss.sgi.com>
To: "machael thailer" <dony.he@huawei.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 21, 2001 5:07 AM
Subject: Re: questions about eret....


> On Mon, Aug 20, 2001 at 05:54:09PM +0800, machael thailer wrote:
>
> >     I have a question to ask about eret.
> >
> >     In RC4xxx/RC32334, after eret finished, does it automatically enable
IE
> > bit of STATUS register?
>
> ERET does not influence the state of the IE bit.

I agree with you, but the RC32334 User manual (14-13 section) say  it does
and say we must run a "CLI" just before eret to disable IE bit in Status
register .

machael thailer

Re: questions about eret....

[Ralf Baechle]

On Tue, Aug 21, 2001 at 09:06:43AM +0800, machael thailer wrote:

> > >     I have a question to ask about eret.
> > >
> > >     In RC4xxx/RC32334, after eret finished, does it automatically enable
> IE
> > > bit of STATUS register?
> >
> > ERET does not influence the state of the IE bit.
> 
> I agree with you, but the RC32334 User manual (14-13 section) say  it does
> and say we must run a "CLI" just before eret to disable IE bit in Status
> register .

That has a different reason.  Eret takes the return address from the
EPC register and if you'd take an exception between restoring that and the
eret you'd loose it's content - crash boom bang.

  Ralf

Re: questions about eret....

[machael thailer]

>
> > > >     I have a question to ask about eret.
> > > >
> > > >     In RC4xxx/RC32334, after eret finished, does it automatically
enable
> > IE
> > > > bit of STATUS register?
> > >
> > > ERET does not influence the state of the IE bit.
> >
> > I agree with you, but the RC32334 User manual (14-13 section) say  it
does
> > and say we must run a "CLI" just before eret to disable IE bit in Status
> > register .
>
> That has a different reason.  Eret takes the return address from the
> EPC register and if you'd take an exception between restoring that and the
> eret you'd loose it's content - crash boom bang.

Yes.
But in the sourece codes, when we finish the exception handlers , we will
run "ret_from_irq" (ret_from_sys_call) in the entry.S and then run macro
"RESTORE_ALL_AND_RET".  The macro does restore all registers and then ERET.
But there is not a "CLI" just before ERET as the user manual suggested. Why?
so when we handle a syscall exception, we do "STI" in the handle_sys(). and
when ret_from_sys_call and we will run this macro "RESTORE_ALL_AND_RET".
because there is not a "CLI" just before ERET , is it possible to have some
problems?

machael thailer

Re: questions about eret....

[machael thailer]

>
> > > >     I have a question to ask about eret.
> > > >
> > > >     In RC4xxx/RC32334, after eret finished, does it automatically
enable
> > IE
> > > > bit of STATUS register?
> > >
> > > ERET does not influence the state of the IE bit.
> >
> > I agree with you, but the RC32334 User manual (14-13 section) say  it
does
> > and say we must run a "CLI" just before eret to disable IE bit in Status
> > register .
>
> That has a different reason.  Eret takes the return address from the
> EPC register and if you'd take an exception between restoring that and the
> eret you'd loose it's content - crash boom bang.

Yes.
But in the sourece codes, when we finish the exception handlers , we will
run "ret_from_irq" (ret_from_sys_call) in the entry.S and then run macro
"RESTORE_ALL_AND_RET".  The macro does restore all registers and then ERET.
But there is not a "CLI" just before ERET as the user manual suggested. Why?
so when we handle a syscall exception, we do "STI" in the handle_sys(). and
when ret_from_sys_call and we will run this macro "RESTORE_ALL_AND_RET".
because there is not a "CLI" just before ERET , is it possible to have some
problems?

machael thailer

Re: questions about eret....

[Ralf Baechle]

On Tue, Aug 21, 2001 at 06:09:19PM +0800, machael thailer wrote:

> Yes.
> But in the sourece codes, when we finish the exception handlers , we will
> run "ret_from_irq" (ret_from_sys_call) in the entry.S and then run macro
> "RESTORE_ALL_AND_RET".  The macro does restore all registers and then ERET.
> But there is not a "CLI" just before ERET as the user manual suggested. Why?
> so when we handle a syscall exception, we do "STI" in the handle_sys(). and
> when ret_from_sys_call and we will run this macro "RESTORE_ALL_AND_RET".
> because there is not a "CLI" just before ERET , is it possible to have some
> problems?

Look again.

  Ralf

Question on porting Linux...

[Shuanglin Wang]

Hi all,

I'm working on porting Linux to a third-part board. I don't know where to start.
Can anyone give me some tips?
By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.  Do
you think it is possible to port Linux to it?  And how difficult will it be?

A lot of thanks,

--Shuanglin

Re: Question on porting Linux...

[jeff_lee]

What is your CPU arch?

Jeff
----- Original Message -----
From: "Shuanglin Wang" <swang@mmc.atmel.com>
To: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 21, 2001 11:17 PM
Subject: Question on porting Linux...


> Hi all,
>
> I'm working on porting Linux to a third-part board. I don't know where to
start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.
Do
> you think it is possible to port Linux to it?  And how difficult will it
be?
>
> A lot of thanks,
>
> --Shuanglin
>

Re: Question on porting Linux...

[jeff_lee]

What is your CPU arch?

Jeff
----- Original Message -----
From: "Shuanglin Wang" <swang@mmc.atmel.com>
To: <linux-mips@oss.sgi.com>
Sent: Tuesday, August 21, 2001 11:17 PM
Subject: Question on porting Linux...


> Hi all,
>
> I'm working on porting Linux to a third-part board. I don't know where to
start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.
Do
> you think it is possible to port Linux to it?  And how difficult will it
be?
>
> A lot of thanks,
>
> --Shuanglin
>

Re: Question on porting Linux...

[Shuanglin Wang]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

> What is your CPU arch?

MIPS 5kc.

>
>
> Jeff
> ----- Original Message -----
> From: "Shuanglin Wang" <swang@mmc.atmel.com>
> To: <linux-mips@oss.sgi.com>
> Sent: Tuesday, August 21, 2001 11:17 PM
> Subject: Question on porting Linux...
>
> > Hi all,
> >
> > I'm working on porting Linux to a third-part board. I don't know where to
> start.
> > Can anyone give me some tips?
> > By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.
> Do
> > you think it is possible to port Linux to it?  And how difficult will it
> be?
> >
> > A lot of thanks,
> >
> > --Shuanglin
> >

--
Shuanglin Wang
Atmel Multimedia & Communications
3800 Gateway Centre, Suite 311
Morrisville, NC 27560



[-- Attachment #2: Type: text/html, Size: 927 bytes --]

Re: Question on porting Linux...

[Jun Sun]

Shuanglin Wang wrote:
> 
> Hi all,
> 
> I'm working on porting Linux to a third-part board. I don't know where to start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.  Do
> you think it is possible to port Linux to it?  And how difficult will it be?
> 
> A lot of thanks,
> 

Porting Linux/MIPS generally involves three tasks:

1. CPU support

If your CPU is already supported, then your task is as easy as include the
CONFIG_CPU_XXXX in your config file.

2. board support

This involves several subtasks:

a) hook your board/machines to the system.  Check include/asm/bootinfo.h,
arch/mips/setup.c.

b) prom_init().

c) board setup code (xxx_setup()): fix hardware, set Linux variables, etc

d) interrupt dispatching, time service

e) others

Look under various arch/mips subdirectories.

3) driver code

Serial, ether, etc.

Good luck.

Jun

Re: Question on porting Linux...

[Carsten Langgaard]

You are probably referring to the MIPS SEAD board, I have made a port for that board
now.
It runs with a small ramdisk, which basically only consist of a stand-alone shell
and a few simple commands like ls, etc...
So you can't do much with it, but you can make you own ramdisk, and just merge it in
with the kernel.
I will try to put an image on our FTP site
(ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/) tomorrow.

/Carsten

Shuanglin Wang wrote:

> Hi all,
>
> I'm working on porting Linux to a third-part board. I don't know where to start.
> Can anyone give me some tips?
> By the way, the board doesn't have PCI bus, Interrupt controller, and RTC.  Do
> you think it is possible to port Linux to it?  And how difficult will it be?
>
> A lot of thanks,
>
> --Shuanglin

Re: Question on porting Linux...

[Shuanglin Wang]

> You are probably referring to the MIPS SEAD board, I have made a port for that board
> now.
> It runs with a small ramdisk, which basically only consist of a stand-alone shell
> and a few simple commands like ls, etc...
> So you can't do much with it, but you can make you own ramdisk, and just merge it in
> with the kernel.
> I will try to put an image on our FTP site
> (ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/) tomorrow.
>
> /Carsten
>

Yes, it is a MIPS SEAD-2 board. By the way, can I get the source code of the kernel
with SEAD-2 board support ?

>

Re: Question on porting Linux...

[Carsten Langgaard]

You can find a kernel images for the SEAD board here:
ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/vmlinux-2.4.3.sead.el-01.01.srec.gz
The sources are here:
ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/src/linux-2.4.3.mips-src-01.01.tar.gz

To build your own ramdisk see Documentation/initrd.txt (in the sources) for how-to do it.
Put your ramdisk images in arch/mips/ramdisk/ramdisk.gz and compile the kernel (you can
use the .config.sead file for configure your kernel for the SEAD board, just copy it to
.config and then do 'make config').
Note that you need a other MIPS linux system to build your ramdisk.

Hope this is useful.
/Carsten


Shuanglin Wang wrote:

> > You are probably referring to the MIPS SEAD board, I have made a port for that board
> > now.
> > It runs with a small ramdisk, which basically only consist of a stand-alone shell
> > and a few simple commands like ls, etc...
> > So you can't do much with it, but you can make you own ramdisk, and just merge it in
> > with the kernel.
> > I will try to put an image on our FTP site
> > (ftp://ftp.mips.com/pub/linux/mips/kernel/2.4/images/) tomorrow.
> >
> > /Carsten
> >
>
> Yes, it is a MIPS SEAD-2 board. By the way, can I get the source code of the kernel
> with SEAD-2 board support ?
>
> >

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

questions about some bits of STATUS register and exception priority...

[machael thailer]

hello:

    I am confused about CU0 and UM(ERL EXL) bit of STATUS register.

    The user manual says that " CP0 is always usable when in Kernel mode,
regardless of the setting of CU0 bit". Does it mean that when in Kernel mode
, the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0 is
0, can we be sure that it is in User mode?

     If a user program is running in User mode, an interrupt happens at this
time(or an error occurs), then it will switch to Kernel mode to run the
interrupt handler(or the error exception handler). We know that the EXL(or
ERL) bit of Status register will be set to 1 by hardware. What about the UM
bit of Status? Does it remain unchangeable or change to 1 too? The user
manual doesn't say anything about it.


Another question about exception priority:
In entry.S, some exception handlers enables global interrupt bit(IE) but
others disables it.
Also syscall exception handler enables global interrupt bit(IE). Since the
interrupt priority  is lowest,If an interrupt happens in a syscall exception
handler, will it pause the syscall exception handler and run the interrupt
handler? If not, why it enable the IE bit(STI) in the syscall exception
handler??

If two interrupts happens at the same time, how can we decide the larger
priority interrupt and run its ISR?

Thank you very much.

machael thailer

questions about some bits of STATUS register and exception priority...

[machael thailer]

hello:

    I am confused about CU0 and UM(ERL EXL) bit of STATUS register.

    The user manual says that " CP0 is always usable when in Kernel mode,
regardless of the setting of CU0 bit". Does it mean that when in Kernel mode
, the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0 is
0, can we be sure that it is in User mode?

     If a user program is running in User mode, an interrupt happens at this
time(or an error occurs), then it will switch to Kernel mode to run the
interrupt handler(or the error exception handler). We know that the EXL(or
ERL) bit of Status register will be set to 1 by hardware. What about the UM
bit of Status? Does it remain unchangeable or change to 1 too? The user
manual doesn't say anything about it.


Another question about exception priority:
In entry.S, some exception handlers enables global interrupt bit(IE) but
others disables it.
Also syscall exception handler enables global interrupt bit(IE). Since the
interrupt priority  is lowest,If an interrupt happens in a syscall exception
handler, will it pause the syscall exception handler and run the interrupt
handler? If not, why it enable the IE bit(STI) in the syscall exception
handler??

If two interrupts happens at the same time, how can we decide the larger
priority interrupt and run its ISR?

Thank you very much.

machael thailer

Re: questions about some bits of STATUS register and exception priority...

[Ralf Baechle]

On Tue, Aug 21, 2001 at 09:34:00AM +0800, machael thailer wrote:

>     I am confused about CU0 and UM(ERL EXL) bit of STATUS register.
> 
>     The user manual says that " CP0 is always usable when in Kernel mode,
> regardless of the setting of CU0 bit". Does it mean that when in Kernel mode
> , the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0 is
> 0, can we be sure that it is in User mode?

In the Linux kernel CU0 is used to indicate that we're running on the
kernel stack.

>      If a user program is running in User mode, an interrupt happens at this
> time(or an error occurs), then it will switch to Kernel mode to run the
> interrupt handler(or the error exception handler). We know that the EXL(or
> ERL) bit of Status register will be set to 1 by hardware. What about the UM
> bit of Status? Does it remain unchangeable or change to 1 too? The user
> manual doesn't say anything about it.

The hardware does not change UM (r4k: KSU bits).

> Another question about exception priority:
> In entry.S, some exception handlers enables global interrupt bit(IE) but
> others disables it.

We have to avoid infinite recursion of exceptions; in same cases it's
just paranoia or minor performance issue.

> Also syscall exception handler enables global interrupt bit(IE). Since the
> interrupt priority  is lowest,If an interrupt happens in a syscall exception
> handler, will it pause the syscall exception handler and run the interrupt
> handler? If not, why it enable the IE bit(STI) in the syscall exception
> handler??
> 
> If two interrupts happens at the same time, how can we decide the larger
> priority interrupt and run its ISR?

That's the decission of implementor of the respective board.  No strict
rules here; in general we priorize the timer interrupt highest but that's
no longer mandatory.

  Ralf

Re: questions about some bits of STATUS register and exception priority...

[machael thailer]

> On Tue, Aug 21, 2001 at 09:34:00AM +0800, machael thailer wrote:
>
> >     I am confused about CU0 and UM(ERL EXL) bit of STATUS register.
> >
> >     The user manual says that " CP0 is always usable when in Kernel
mode,
> > regardless of the setting of CU0 bit". Does it mean that when in Kernel
mode
> > , the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0
is
> > 0, can we be sure that it is in User mode?
>
> In the Linux kernel CU0 is used to indicate that we're running on the
> kernel stack.

Yes, when CU0 is 1, we can see we are running on the kernel stack.
But when CU0 is 0, can we say it is in User mode?

>
> > Another question about exception priority:
> > In entry.S, some exception handlers enables global interrupt bit(IE) but
> > others disables it.
>
> We have to avoid infinite recursion of exceptions; in same cases it's
> just paranoia or minor performance issue.
>
> > Also syscall exception handler enables global interrupt bit(IE). Since
the
> > interrupt priority  is lowest,If an interrupt happens in a syscall
exception
> > handler, will it pause the syscall exception handler and run the
interrupt
> > handler? If not, why it enable the IE bit(STI) in the syscall exception
> > handler??


The answer of this question? Thanks.

machael thailer

Re: questions about some bits of STATUS register and exception priority...

[machael thailer]

> On Tue, Aug 21, 2001 at 09:34:00AM +0800, machael thailer wrote:
>
> >     I am confused about CU0 and UM(ERL EXL) bit of STATUS register.
> >
> >     The user manual says that " CP0 is always usable when in Kernel
mode,
> > regardless of the setting of CU0 bit". Does it mean that when in Kernel
mode
> > , the CU0 bit is always 1 and in User mode, the CU0 bit is 0? If the CU0
is
> > 0, can we be sure that it is in User mode?
>
> In the Linux kernel CU0 is used to indicate that we're running on the
> kernel stack.

Yes, when CU0 is 1, we can see we are running on the kernel stack.
But when CU0 is 0, can we say it is in User mode?

>
> > Another question about exception priority:
> > In entry.S, some exception handlers enables global interrupt bit(IE) but
> > others disables it.
>
> We have to avoid infinite recursion of exceptions; in same cases it's
> just paranoia or minor performance issue.
>
> > Also syscall exception handler enables global interrupt bit(IE). Since
the
> > interrupt priority  is lowest,If an interrupt happens in a syscall
exception
> > handler, will it pause the syscall exception handler and run the
interrupt
> > handler? If not, why it enable the IE bit(STI) in the syscall exception
> > handler??


The answer of this question? Thanks.

machael thailer

Re: questions about some bits of STATUS register and exception priority...

[Ralf Baechle]

On Tue, Aug 21, 2001 at 06:53:34PM +0800, machael thailer wrote:

> > In the Linux kernel CU0 is used to indicate that we're running on the
> > kernel stack.
> 
> Yes, when CU0 is 1, we can see we are running on the kernel stack.
> But when CU0 is 0, can we say it is in User mode?

No, think of the tlb exception handlers for example.

  Ralf