From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sccrmhc15.comcast.net (sccrmhc15.comcast.net [204.127.200.85]) by ozlabs.org (Postfix) with ESMTP id A8DFB67BDD for ; Tue, 22 Aug 2006 18:53:43 +1000 (EST) Message-ID: <44EAC607.7010500@dlasys.net> Date: Tue, 22 Aug 2006 04:53:27 -0400 From: "David H. Lynch Jr." MIME-Version: 1.0 To: Wade Maxfield Subject: Re: PPC beginner questions References: <45a1b53e0608210651s4f5de382w77e092463dbbf5b7@mail.gmail.com> In-Reply-To: <45a1b53e0608210651s4f5de382w77e092463dbbf5b7@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------080408020501070404060901" Cc: ppc List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------080408020501070404060901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wade Maxfield wrote: > > I'm new to the PPC and I have a few questions. I have written a > driver in the past for the X86 family, using i/o ports, but it was > kernel 2.0 and i/o ports are not mmu handled. > I've been looking through the archive and I am slowly growing more > confused. The PPC MMU is pretty simple compared to the x86. Basically the MMU unit is a peice of hardware that maps "virtual" addresses to "physical" addresses. Its use is enabled/disabled by two bits in the PPC Machine Status register - 1 for instructions, 1 for data. The MMU itself is basically a 64 entry lookup table. Virtual address X corresponds to physical address Y. When a request is made for an address that is not in the 64 entry MMU table things become more complex - an exception is generated and code inside Linux searches its tables to find the correct entry to stuff into the MMU. NORMALLY there is no correspondence between physical addresses and virtual ones. But it is possible (and might be useful for debugging) to stuff an entry where physical=virtual. If you look inside head_4xx.S for CONFIG_SERIAL_TEXT_DEBUG or something like that you should see how to do it. However manually stuffed entries in the MMU will eventually get blown away. I spent a week trying to trace a problem caused by that down. > > We are using Xilinx with PPC built in. > > The PPC has a memory management unit. All of the IP we've added is > mapped to physical addresses. > > 1. Can I access the memory the peripherasl are mapped to directly > within the driver without going through functions? > if NOT, then Do I use > 1. ioremap(), Once you have done the ioremap(), you can use the address returned exactly the way you would have used the physical address previously. > 2. request_mem_region(), > 3. request_region() > 4. something else? > > 2. Are there any gotcha's with the ppc 405 that Xilinx uses that I > should know about? Are you doing board bringup ? If you are not bringing up a new board - then the big gotcha's should already be covered. If you are doing board bringup - I would recommend following the existing xilinx packages closely. > > > thanks, > wade > > > ------------------------------------------------------------------------ > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770 dhlii@dlasys.net http://www.dlasys.net fax: 1.253.369.9244 Cell: 1.717.587.7774 Over 25 years' experience in platforms, languages, and technologies too numerous to list. "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." Albert Einstein --------------080408020501070404060901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wade Maxfield wrote:

  I'm new to the PPC and I have a few questions.  I have written a  driver in the past for the X86 family, using i/o ports, but it was kernel 2.0 and i/o ports are not mmu handled.
  I've been looking through the archive and I am slowly growing more confused.
    The PPC MMU is pretty simple compared to the x86.
    Basically the MMU unit is a peice of hardware that maps "virtual" addresses to "physical" addresses.
    Its use is enabled/disabled by two bits in the PPC Machine Status register - 1 for instructions, 1 for data.
    The MMU itself is basically a 64 entry lookup table. Virtual address X corresponds to physical address Y.
    When a request is made for an address that is not in the 64 entry MMU table things become more complex
     - an exception is generated and code inside Linux searches its tables to find the correct entry to stuff into the MMU.
    NORMALLY there is no correspondence between physical addresses and virtual ones. But it is possible (and might be useful for debugging) to stuff an entry
    where physical=virtual. If you look inside head_4xx.S for CONFIG_SERIAL_TEXT_DEBUG or something like that you should see how to do it.
    However manually stuffed entries in the MMU will eventually get blown away. I spent a week trying to trace a problem caused by that down.



  We are using Xilinx with PPC built in.

   The PPC has a memory management unit.  All of the IP we've added is mapped to physical addresses.

   1. Can I access the memory the peripherasl are mapped to directly within the driver without going through functions?
       if NOT, then Do I use
          1. ioremap(),
    Once you have done the ioremap(), you can use the address returned exactly the way you would have used the physical address previously.


          2. request_mem_region(),
          3. request_region()
          4. something else?

   2.  Are there any gotcha's with the ppc 405 that Xilinx uses that I should know about?
    Are you doing board bringup ?
    If you are not bringing up a new board - then the big gotcha's should already be covered.
    If you are doing board bringup - I would recommend following the existing xilinx packages closely.


thanks,
wade

 

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
--------------080408020501070404060901--