Calculating virtual address from physical address

[David H. Lynch Jr.]

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 	  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