Calculating virtual address from physical address

[Chris Dumoulin]

Thanks for your reply; I found it very useful and interesting. Now, I have a whole bunch
of questions.

You said that the temporary TLB entries setup in head_4xx.S will eventually be replaced.
Where is the code that creates these new TLB entries later on? Are the 'real' TLB entries
only created once, and persist for as long as the system is running, or do TLB entries
change often while the system is running?

Do you know what state the MSR will be in at this point in the code? I know what the
power-on reset state is, but I'm wondering if it'll be in a different state by the time we
get to this point in head_4xx.S.

When you suggest disabling instruction or data address translation, is that just so I
could access my hardware directly, or is there some other reason?

You were enabling the MSR bits, one at a time, and found that the machine check was
causing the hang (I'm assuming that's what you meant by 'sent me to space'). Was the idea
there to just isolate what type of exception was causing the hang, or were you looking to
make some permanent changes to the MSR? Is a machine check interrupt caused by trying to
access an address that doesn't have a TLB entry?

Can you point me to some information about Grant's platform bus changes that you were
talking about? I am using a custom V2Pro board, and I'd be interested to see if this code
is something I should be looking at.

Thanks alot,
Chris


On May 05, "David H. Lynch Jr." <dhlii at dlasys.net> wrote:
> 
> Chris Dumoulin wrote:
> > My LEDs are at address 0x4F600000 and my CONFIG_KERNEL_START is 
> > 0xC0000000. If this address were low enough, I would just add 0xC0000000 
> > to the address to get the virtual address, but since my LED address is 
> > so high, the sum will be well past the 32-bit maximum address value. How 
> > is a virtual address calculated for a high address like 0x4F600000?
> >   
>     There are macros tophys and tovirt  that convert addresses between
> physical and virtual. There are use example in the head_4xx.S file you
> are already in.
> 
>     If you are going to use a port for debugging you need to create a
> tlb entry for it.
>     Same file in initial_mmu the code inside the if
> defined(CONFIG_SERIAL_TEXT_DEBUG) should provide an example how to do that.
> 
>     Be forwarned that any entries you create now will eventually
> disappear (took 2 weeks to figure that out once), but that may not
> happen intil after /init starts.
> 
>     Also with a little of jiggering arround the bits in MSR_KERNEL you
> can enable Data address translation independently of instruction address
> translation as well as disable or enable a variety of
>     checks. It took me three weeks to get a new Xilinx V4 board through
> the rfi and to start_here in the same turn_on_mmu code you are working on.
> 
>     Eventually I ended up enabling the MSR bits one at a time until I
> discovered that enabling the Machine Check sent me to space.
> 
>     Regardless, once I relialized I could test the code with the MSR
> bits enabled one at a time isolating the problem became easier.
> 
>    
>     The two issues I addressed above which relate specifically to your
> efforts with the ml300, constituted more than 80% of my effort to get a
> Xilinx Virtex 4 running.
> 
>     Finally, I started prior to grants platform bus changes. I have been
> adapting my V4 code to fit with Grants changes (the client has what they
> want so they do not care)
>     I have not put alot of effort into this, but I currently get
> waylayed much later in new platform bus specific initialization code.
>     I had no problem with the older board specific initialization code.
> 
>     If you are running on a real ml300 I am surprised you are having any
> problems though I do not have an ml300 to check that.
>     But if you are running on a custom V2Pro board you have to get the
> board specific initalization right and therefore could trip over the
> issue I am currently having migrating from old to new.
> 
> 
> 
>    
> 
> 
> 
> > BTW, he is the assembly code that I'm working with (from 
> > arch/ppc/kernel/head_4xx.S):
> >
> >     .text
> > _GLOBAL(_stext)
> > _GLOBAL(_start)
> >
> >     /* Save parameters we are passed.
> >     */
> >     mr    r31,r3
> >     mr    r30,r4
> >     mr    r29,r5
> >     mr    r28,r6
> >     mr    r27,r7
> >    
> >     /* CRD: set LED state here */
> >     lis    r26,0x4F600000 at h
> >     ori    r26,r26,0x4F600000 at l
> >     li  r25,LED_STATE_0
> >     stw r25,0(r26)
> >    
> >     /* We have to turn on the MMU right away so we get cache modes
> >      * set correctly.
> >      */
> >     bl    initial_mmu
> >    
> >     /* CRD: set LED state here */
> >     lis    r26,0x4F600000 at h
> >     ori    r26,r26,0x4F600000 at l
> >     li  r25,LED_STATE_1
> >     stw r25,0(r26)
> >
> > /* We now have the lower 16 Meg mapped into TLB entries, and the caches
> >  * ready to work.
> >  */
> > turn_on_mmu:
> >     lis    r0,MSR_KERNEL at h
> >     ori    r0,r0,MSR_KERNEL at l
> >     mtspr    SPRN_SRR1,r0
> >     lis    r0,start_here at h
> >     ori    r0,r0,start_here at l
> >     mtspr    SPRN_SRR0,r0
> >     SYNC
> >    
> >     /* CRD: set LED state here */
> >     lis    r26,0x4F600000 at h
> >     ori    r26,r26,0x4F600000 at l
> >     li  r25,LED_STATE_2
> >     stw r25,0(r26)
> >    
> >     rfi                /* enables MMU */
> >    
> >     /* CRD: set LED state here */
> >     /* This address should be a virtual address */
> >     lis    r26,0x4F600000 at h
> >     ori    r26,r26,0x4F600000 at l
> >     li  r25,LED_STATE_3
> >     stw r25,0(r26)
> >    
> >     b    .            /* prevent prefetch past rfi */
> >
> > Regards,
> > Chris Dumoulin
> >   
> 
> 
> -- 
> Dave Lynch 					  	    DLA Systems
> Software Development:  				         Embedded Linux
> 717.627.3770 	       dhlii at dlasys.net 	  <a
href='http://www.dlasys.net'>http://www.dlasys.net</a>
> 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
> 
>