new platform

new platform

[Emmanuel Michon]

Hi,

I plan to port linux-mips to a a 32bit 4KEc based (little endian)
hardware design.

I have three questions:

Q1- The nice book `see mips run' states that it's better that the
physical address map fits entirely in kseg1 (in 0x0-0x2000_0000).

I would not be the first to plan for a lot of RAM and I understand
HIGHMEM patch is ok if an extra RAM area is out of reach of kseg1.

But what if my PCI devices I/O do not lie in kseg1? I may program the
TLB to see them thru kseg2 (but kseg2 seems to be the place where page
tables are stored...)

Q2- Most hardware platforms have their SDRAM chips mapped at
physical address 0x0. Mine does not. Am I going ahead of problems?
It seems to be assumed at a lot of places (I have already ported YAMON).

Q3- I'd rather stick to a 2.4.x linux port. But... should I use:

a- the latest official 2.4.x kernel
b- the latest 2.4.x-preY kernel
c- the latest linux-mips.org 2.4.x kernel
d- cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4
?

Thanks for any useful advise.

Sincerely yours,

-- 
E.M.
key A1A84D4C

Re: new platform

[Stanislaw Skowronek]

> Q2- Most hardware platforms have their SDRAM chips mapped at
> physical address 0x0. Mine does not. Am I going ahead of problems?
> It seems to be assumed at a lot of places (I have already ported YAMON).

I have run into very few problems of the sort on the Octane, which has all
its memory just over CKSEG0. Most, if not all, of them would be gone if
the Octane had anything at all in CKSEG0, not counting exception vectors
(that reminds me, how do you handle exceptions? Linux assumes you *DO*
have some writeable space at CKSEG0, at least a kilobyte - all exception
handlers are copied there at runtime).

You will have to change the kernel link address to the beginning of your
physical RAM (or any other place you like, as long as it is under 512MB).
It is easily done and I don't think it will cause any problems.

Stanislaw Skowronek

Re: new platform

[Emmanuel Michon]

On Mon, 2004-05-10 at 16:53, Stanislaw Skowronek wrote:
> > Q2- Most hardware platforms have their SDRAM chips mapped at
> > physical address 0x0. Mine does not. Am I going ahead of problems?
> > It seems to be assumed at a lot of places (I have already ported YAMON).
> 
> I have run into very few problems of the sort on the Octane, which has all
> its memory just over CKSEG0. Most, if not all, of them would be gone if
> the Octane had anything at all in CKSEG0, not counting exception vectors
> (that reminds me, how do you handle exceptions? Linux assumes you *DO*
> have some writeable space at CKSEG0, at least a kilobyte - all exception
> handlers are copied there at runtime).

It seems not all MIPS CPUs have the CP0 register EBase but mine does

This one allows to use any value as exception base instead of
0x8000_0000 (that saves me: I will just point it at the base of my RAM).

Sincerely yours,

E.M.

> 
> You will have to change the kernel link address to the beginning of your
> physical RAM (or any other place you like, as long as it is under 512MB).
> It is easily done and I don't think it will cause any problems.
> 
> Stanislaw Skowronek
> 
> 
> 
> 

Re: new platform

[Ralf Baechle]

On Mon, May 10, 2004 at 04:24:51PM +0200, Emmanuel Michon wrote:

> I plan to port linux-mips to a a 32bit 4KEc based (little endian)
> hardware design.
> 
> I have three questions:
> 
> Q1- The nice book `see mips run' states that it's better that the
> physical address map fits entirely in kseg1 (in 0x0-0x2000_0000).
> 
> I would not be the first to plan for a lot of RAM and I understand
> HIGHMEM patch is ok if an extra RAM area is out of reach of kseg1.

Using highmem in general is a baaad idea.  The option only exists at all
for MIPS because of a user who didn't want to try something as unorthodox
as 64-bit kernels ...

Highmem implies significant extra overhead and complexity for software
that runs in kernel space.  Avoid like the plague if you can.

> But what if my PCI devices I/O do not lie in kseg1? I may program the
> TLB to see them thru kseg2 (but kseg2 seems to be the place where page
> tables are stored...)

Doesn't really matter.  It's nice to have devices in the lower 512MB of
physical address space because that means the TLB will not be used - a
nice performance bonus.

Whatever - the driver API to use is ioremap.

> Q2- Most hardware platforms have their SDRAM chips mapped at
> physical address 0x0. Mine does not. Am I going ahead of problems?

It won't work ;-)

You at least need some memory at physical address zero because exception
vectors are located in the first few k of physical address space.  Of
course you could avoid that by having the BEV bit set in the status
register so exceptions would go via 0xbfc00000 - but that's an uncached
address, likely even in a flash so performance would go down the drain ...

> It seems to be assumed at a lot of places (I have already ported YAMON).
> 
> Q3- I'd rather stick to a 2.4.x linux port. But... should I use:

Depending on what exactly you want to do you should take a look at 2.6.

> a- the latest official 2.4.x kernel
> b- the latest 2.4.x-preY kernel

kernel.org kernels won't work out of the box or at least your chances
are worse due to the lag in merging MIPS code from to kernel.org.

> c- the latest linux-mips.org 2.4.x kernel
> d- cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4

D - where C and D are the basically the same anyway - I've stopped making
snapshot tarballs years ago, so you'll have to fetch from cvs.

  Ralf

Re: new platform

[Emmanuel Michon]

On Mon, 2004-05-10 at 23:49, Ralf Baechle wrote:
> On Mon, May 10, 2004 at 04:24:51PM +0200, Emmanuel Michon wrote:
> 
> > I plan to port linux-mips to a a 32bit 4KEc based (little endian)
> > hardware design.
> > 
> > I have three questions:
> > 
> > Q1- The nice book `see mips run' states that it's better that the
> > physical address map fits entirely in kseg1 (in 0x0-0x2000_0000).
> > 
> > I would not be the first to plan for a lot of RAM and I understand
> > HIGHMEM patch is ok if an extra RAM area is out of reach of kseg1.
> 
> Using highmem in general is a baaad idea.  The option only exists at all
> for MIPS because of a user who didn't want to try something as unorthodox
> as 64-bit kernels ...
> 
> Highmem implies significant extra overhead and complexity for software
> that runs in kernel space.  Avoid like the plague if you can.
> 
> > But what if my PCI devices I/O do not lie in kseg1? I may program the
> > TLB to see them thru kseg2 (but kseg2 seems to be the place where page
> > tables are stored...)
> 
> Doesn't really matter.  It's nice to have devices in the lower 512MB of
> physical address space because that means the TLB will not be used - a
> nice performance bonus.
> 
> Whatever - the driver API to use is ioremap.

You mean that after basic probing you always access PCI devices thru the
TLB?

> 
> > Q2- Most hardware platforms have their SDRAM chips mapped at
> > physical address 0x0. Mine does not. Am I going ahead of problems?
> 
> It won't work ;-)
> 
> You at least need some memory at physical address zero because exception
> vectors are located in the first few k of physical address space.  Of
> course you could avoid that by having the BEV bit set in the status
> register so exceptions would go via 0xbfc00000 - but that's an uncached
> address, likely even in a flash so performance would go down the drain ...

Well my 4KEc core has a CP0 register called EBase (15 select 1) that
allows to put the vectors anywhere (excepted reset/softreset/nmi/ejtag).

> 
> > It seems to be assumed at a lot of places (I have already ported YAMON).
> > 
> > Q3- I'd rather stick to a 2.4.x linux port. But... should I use:
> 
> Depending on what exactly you want to do you should take a look at 2.6.
> 
> > a- the latest official 2.4.x kernel
> > b- the latest 2.4.x-preY kernel
> 
> kernel.org kernels won't work out of the box or at least your chances
> are worse due to the lag in merging MIPS code from to kernel.org.
> 
> > c- the latest linux-mips.org 2.4.x kernel
> > d- cvs -z3 -d :pserver:cvs@ftp.linux-mips.org:/home/cvs co -r linux_2_4
> 
> D - where C and D are the basically the same anyway - I've stopped making
> snapshot tarballs years ago, so you'll have to fetch from cvs.

Thanks

Sincerely yours,

E.M.

> 
>   Ralf
> 
> 

Re: new platform

[Ralf Baechle]

On Tue, May 11, 2004 at 11:22:22AM +0200, Emmanuel Michon wrote:

> > Whatever - the driver API to use is ioremap.
> 
> You mean that after basic probing you always access PCI devices thru the
> TLB?

No.  ioremap knows how to optimize this for physical addresses that are
mapped via KSEG1.  So this just doesn't matter to driver writers.

  Ralf