accessing immap_t * variable in mpc8260

accessing immap_t * variable in mpc8260

[Omanakuttan]

Hi,
We are writing existing drivers for mpc8260 FCC and writing new ones for
MCC. we are unable to small (may be foolish) problem of accessing immap
address registers.

In FCC code, eldk/ppc_82xx/usr/src/linux/arch/ppc/8260_io/fcc_enet.c,
immap_t * immap is simply typecasted to IMAP_ADDR, which is
((uint)0xf0000000).
Now, after assigning this physical address, fcc_enet code continues the
immap_t variable without doing any __va macro.

I am confused at this point, that how can kernel code access a physical
address as if it were virtual address ? how does the page frame -> page
conversion (and vice versa) happens on this front?

Thanks and regards,
Om.


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

Re: accessing immap_t * variable in mpc8260

[Dan Malek]

Omanakuttan wrote:

> I am confused at this point, that how can kernel code access a physical
> address as if it were virtual address ? how does the page frame -> page
> conversion (and vice versa) happens on this front?

There are some kernel address spaces that are mapped 1:1 virtual
to physical, that is, the virtual address matches the physical one.
Sometimes it is for convenience, sometimes it just works that way.
Sometimes it is because we need to access a space with the MMU
disabled and it is easier this way.

The IMMR is one such space that is mapped this way.


	-- Dan


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

Re: accessing immap_t * variable in mpc8260

[Paul Mackerras]

Omanakuttan writes:

> In FCC code, eldk/ppc_82xx/usr/src/linux/arch/ppc/8260_io/fcc_enet.c,
> immap_t * immap is simply typecasted to IMAP_ADDR, which is
> ((uint)0xf0000000).
> Now, after assigning this physical address, fcc_enet code continues the
> immap_t variable without doing any __va macro.

The __va macro is only applicable to addresses in system RAM.  If you
are using "HIGHMEM" support (unlikely on an 82xx) you can only use
__va on "low" memory addresses, i.e. those that are mapped
contiguously starting at KERNELBASE.

> I am confused at this point, that how can kernel code access a physical
> address as if it were virtual address ? how does the page frame -> page
> conversion (and vice versa) happens on this front?

The 8xx and 82xx ports map several things at the same virtual address
as their physical address.  That simplifies some things but has the
disadvantage that it tends to clutter up the kernel virtual address
space.  If you have no more than 512MB of RAM or so, that isn't a big
problem.  On powermac/CHRP/PReP machines we no longer map anything at
fixed virtual addresses, because those machines can have a gigabyte or
more of RAM.

Paul.

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

Re: accessing immap_t * variable in mpc8260

[Omanakuttan]

Thanks for the answers. Now I have a better picture, still some more
doubts...

Paul Mackerras wrote:
> Omanakuttan writes:
>
>
>>In FCC code, eldk/ppc_82xx/usr/src/linux/arch/ppc/8260_io/fcc_enet.c,
>>immap_t * immap is simply typecasted to IMAP_ADDR, which is
>>((uint)0xf0000000).
>>Now, after assigning this physical address, fcc_enet code continues the
>>immap_t variable without doing any __va macro.
>
>
> The __va macro is only applicable to addresses in system RAM.  If you
> are using "HIGHMEM" support (unlikely on an 82xx) you can only use
we are not using it, and I thought it is a intel feature, to address
64GB mem. Thanks for this input. We have 64MB SDRAM and 8MB FLASH.
> __va on "low" memory addresses, i.e. those that are mapped
> contiguously starting at KERNELBASE.
>
>
>>I am confused at this point, that how can kernel code access a physical
>>address as if it were virtual address ? how does the page frame -> page
>>conversion (and vice versa) happens on this front?
>
>
> The 8xx and 82xx ports map several things at the same virtual address
Sorry for asking shortcut, but which files in the source tree will give
me the exact mapping? shall I start exploring mm directory in ppc/arch?
will init.c and pgtable.c give what I want?
> as their physical address.  That simplifies some things but has the
OK, now if I use __va on such an address, it will not do any harm,
right? if both physical and virtual address are same, I cannot think of
any way __va(x) or __pa(x) returning something other than x . But again
the implementation of __va
#define ___va(paddr) ((paddr)+PPC_MEMOFFSET)
where PPC_MEMOFFSET is  CONFIG_KERNEL_START or 0xc000_0000, but it
implies that va is pa+3GB or custom kernel start address.
Now if the memory manager maps pa+3GB back to pa, I think there will be
no problem. Is it what happens? if so, how can we tell virtual and phy
address are same?
> disadvantage that it tends to clutter up the kernel virtual addres
> space.  If you have no more than 512MB of RAM or so, that isn't a big
> problem.  On powermac/CHRP/PReP machines we no longer map anything at
> fixed virtual addresses, because those machines can have a gigabyte or
> more of RAM.
>
> Paul.
>

Thanks and regards,
Om.


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