MMU in MBX860

MMU in MBX860

[Okehee Goh]

 Hi,
 This question is about MMU of MBX860 using MPC860 rather than LinuxPPC.
 I'm sorry to send not proper question to this board. Thank you so much if
you let me know proper and also active group.

 My question:
 In MPC860, is there any way for supervisor mode's kernel to access all
memory space
  whether its ASID matches with M_CASID even though some of memory space is
  configured to check ASID?

 I appreciate any help.

 My situation:
  I'm porting a microkernel into MBX860 using MPC860.
 For memory protection, this uses MMU even though address translation is not
necessary.
 Only one global memory address page table managed by kernel includes all
page table information for
  all application tasks for performance.
 It is possible by allocating memory space into each of application tasks.
 The requirements is that kernel in Privilege state can access all the
memory space
  but application task's access is restricted to the a memory space
allocated to itself.
 I think that the access violation between applications can be checked by
using ASID.
 So, I assign each ASID for memory space for applications and kernel.
 But I guess when ASID checking is enabled, kernel also can't access other
application's
  memory space because its ASID is different with others' ASID.

 Thank you so much.

 Okehee Goh





 ---------------------------------------
Real-Time System lab of CSE of ASU
Tel: 480-219-1346


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MMU in MBX860

[Dan Malek]

Okehee Goh wrote:

>  My question:
>  In MPC860, is there any way for supervisor mode's kernel to access all
> memory space

That's the purpose of the SHARED indicator in the TLB.  It effectively
disables ASID checking and if you mark pages SHARED but not user access
the kernel can access all pages while the applications are still protected.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: MMU in MBX860

[Okehee Goh]

 Thank you, Dan

 The problem is that it shares one global page table between kernel and
application processes.
 Some of memory space that is allocated to each application process must be
accessed by
 that application process. In other word, it must prevent an application
process from accessing to
 memory space allocated to other an application process. For this
protection, I need to use ASID.
 If memory space are marked as SHARED and suprevisor permission, kernel can
access all of memory space
  because ASID checking is disabled.
 But it can't support memory protection for application processes.

 I appreciate any your idea.
 Thank you so much.

 Okehee


-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Dan
Malek
Sent: Wednesday, October 24, 2001 9:01 PM
To: Okehee Goh
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: MMU in MBX860



Okehee Goh wrote:

>  My question:
>  In MPC860, is there any way for supervisor mode's kernel to access all
> memory space

That's the purpose of the SHARED indicator in the TLB.  It effectively
disables ASID checking and if you mark pages SHARED but not user access
the kernel can access all pages while the applications are still protected.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: MMU in MBX860

[Dan Malek]

Okehee Goh wrote:

>  The problem is that it shares one global page table between kernel and
> application processes.

You can support any type of memory mapping and protection you wish using a
combination of features supported by the 8xx MMU and standard operating
system mapping techniques.  What you are asking to do isn't difficult, but
asking us to design your system for you in a reasonable period of time
isn't likely to happen on this mailing list :-).

Good Luck.

	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

405GP Dhrystone Benchmark

[ibm405.linux]

Hi,

Does anyone perform Dhrystone 2.1 benchmark with a 405GP  ?
I've tried and i got : 172 Mips  (Walnut board @200Mhz, HHL2.0).
I've also tried to run the same benchmark with the same board with the
basic_os and the ibm "highcppc" compiler and i found
237 Mips (the 405GP specifications give 282 Mips @200Mhz, they told me that
was obtained with a Diab compiler).
Is there any reason my result (172 Mips) is so far from ~240 Mips.
(i've used  : ppc_405-gcc   -DUNIX -DROPT -O2 -fomit-frame-pointer   dhry21a.c
dhry21b.c timers_b.c -o dhry21 )

thanks,
Phil.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Dhrystone Benchmark

[Mark Hatle]

"ibm405.linux" wrote:
>
> Hi,
>
> Does anyone perform Dhrystone 2.1 benchmark with a 405GP  ?
> I've tried and i got : 172 Mips  (Walnut board @200Mhz, HHL2.0).
> I've also tried to run the same benchmark with the same board with the
> basic_os and the ibm "highcppc" compiler and i found
> 237 Mips (the 405GP specifications give 282 Mips @200Mhz, they told me that
> was obtained with a Diab compiler).
> Is there any reason my result (172 Mips) is so far from ~240 Mips.
> (i've used  : ppc_405-gcc   -DUNIX -DROPT -O2 -fomit-frame-pointer   dhry21a.c
> dhry21b.c timers_b.c -o dhry21 )

(To truely do a valid test you need to compare the compiler output when
running on the same OS, otherwise the numbers can not be validly
compared due to OS overhead, i.e. context switching.... but to address
you compiler question...)

This is just a guess... but...

GCC is a "generic" compiler.  It is designed to run on as many platforms
as possible and as such has to make some specific performance sacrifices
to remain portable.

Whereas IBM has the resources to make a compiler that is ultra fast on a
PPC system, it probably doesn't work (or at least wouldn't be the same
code-base) on say an intel system, HPPA, sh, mips, arm, etc systems..

So you are trading compatability for speeds.  (In most cases
compatability wins..)  For example think of the TiVo.  The hardware is
one component of the system, but the software is the true masterpiece.
If TiVo decides that the PPC isn't the best hardware or they can get
cheaper parts from another supplier they don't need to completely port
their code to a new compiler.  (Assuming no assembly) they could take
their user code and recompile it for another architecture.  They could
also maintain a code base between processors and update older and newer
units.  (This is all obviously hypothetical...)

The other thing to keep in mind is that some compilers (*note: I have
never used "diab" before so I am talking generically*) have been known
to have specific optimizations that boost performance benchmarks but do
little or not good in the real world.

Moral of the story, if you plan on using Linux, plan to use GCC.  If GCC
isn't fast enough for you, you have two options.

1) Find a commericial compiler that will produce Linux binaries
2) Help find and improve GCC

(2 is the preferable approach...)

--Mark
(I don't normally add this disclaimer, but these are my opinions and not
my employer's!)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/