ioremap and related

ioremap and related

[Jeff Rugen]

I have a few questions related to the ioremap function and some related
ones.

First, is ioremap the kernel equivalent of using mmap?  I'm working on the
clgenfb device for LinuxPPC on a Motorola Powerstack, and I'm currently
thinking my problems are coming from setting up the framebuffer memory and
PCI stuff.  I have the source for Xbh, and it uses mmap() to map the I/O
registers, video memory, and PCI memory (not sure what the third is for, but
I have a question related to that below).

Now, in the clgenfb driver, it doesn't seem to like me using ioremap to set
up the registers for the Cirrus chip -- if I hard-code the registers to be
relative to 0x80000000, everything works fine (this is the memory location
mmaped in in Xbh server), but if I use ioremap, it doesn't work.
(By working, I mean it sets the video mode and sets/reads the color
registers... not working means I get a panic when starting to
initizliaze the hardware and can't detect the video memory size). 

However, it seems I get a little farther if I ioremap video memory (mmapped
from 0xC0000000 in Xbh) than if I don't -- though the program crashes in
either case.  I'm also trying to use other framebuffer devices as reference,
but I'm not as familiar with them.

In addition, when I use ioremap for video memory, I get the following memory
locations in pointers:
video_phys = 0xc0000000, video_base = 0xc8000000
where video_phys is the physical address and video_base is the ioremapped.
However, when I use phys_to_virt and virt_to_phys, I get strange values
(maybe its related to how much actual memory I have -- 96MB -- some bits may
not be decoded.)
phys_to_virt(video_phys) = 0x80000000
virt_to_phys(video_base) = 0x08000000

I expected the same numbers as above, but don't completely understand how
the functions work yet.

Finally, in Xbh, they do the following code with PCI stuff -- but I don't
really know what they're doing and was wondering if someone could explain it
in a sentence or two and indicate a good reference to look at to understand
it better (online if possible).  An equivalent that you would use in kernel
code would be cool too, but I don't expect that.  ;-)

#define PCI_BASE   ((volatile unsigned long *) 0x80808000)
pcibase = (char *) mmap(..., PCI_BASE);  /* Just to show that its mmaped */
gd->pci04 = 0x03000000;   /* enable memory and I/O accesses */
gd->pci10 = 0x00000000;
*(pcibase + 1) = gd->pci04;    /* 0x80808004 = gd->pci04? */
*(pcibase + 4) = gd->pci10;    /* 0x80808010 = gd->pci10? */

Thanks for any help.

----------------------------------------------------------------------------
Jeff Rugen                      jrugen@primenet.com

...Had this been an actual emergency, we would have fled in terror, and you 
would not have been informed.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: ioremap and related

[Geert Uytterhoeven]

On Mon, 14 Dec 1998, Jeff Rugen wrote:
> I have a few questions related to the ioremap function and some related
> ones.
> 
> First, is ioremap the kernel equivalent of using mmap?  I'm working on the

Yes. ioremap() takes a physical address and size, and maps that block into
kernel space.

> clgenfb device for LinuxPPC on a Motorola Powerstack, and I'm currently
> thinking my problems are coming from setting up the framebuffer memory and
> PCI stuff.  I have the source for Xbh, and it uses mmap() to map the I/O
> registers, video memory, and PCI memory (not sure what the third is for, but
> I have a question related to that below).
> 
> Now, in the clgenfb driver, it doesn't seem to like me using ioremap to set
> up the registers for the Cirrus chip -- if I hard-code the registers to be
> relative to 0x80000000, everything works fine (this is the memory location
> mmaped in in Xbh server), but if I use ioremap, it doesn't work.
> (By working, I mean it sets the video mode and sets/reads the color
> registers... not working means I get a panic when starting to
> initizliaze the hardware and can't detect the video memory size). 
> 
> However, it seems I get a little farther if I ioremap video memory (mmapped
> from 0xC0000000 in Xbh) than if I don't -- though the program crashes in
> either case.  I'm also trying to use other framebuffer devices as reference,
> but I'm not as familiar with them.
> 
> In addition, when I use ioremap for video memory, I get the following memory
> locations in pointers:
> video_phys = 0xc0000000, video_base = 0xc8000000
> where video_phys is the physical address and video_base is the ioremapped.

OK.

> However, when I use phys_to_virt and virt_to_phys, I get strange values
> (maybe its related to how much actual memory I have -- 96MB -- some bits may
> not be decoded.)
> phys_to_virt(video_phys) = 0x80000000
> virt_to_phys(video_base) = 0x08000000
> 
> I expected the same numbers as above, but don't completely understand how
> the functions work yet.

phys_to_virt() and virt_to_phys() don't work that well on MMIO. I was told
they're for real memory only.

That's why most frame buffer devices remember both the physical address (as
passed to ioremap()) and the virtual address (as returned by ioremap()).

> Finally, in Xbh, they do the following code with PCI stuff -- but I don't
> really know what they're doing and was wondering if someone could explain it
> in a sentence or two and indicate a good reference to look at to understand
> it better (online if possible).  An equivalent that you would use in kernel
> code would be cool too, but I don't expect that.  ;-)
> 
> #define PCI_BASE   ((volatile unsigned long *) 0x80808000)

These are accesses to the PCI configuration space, using PReP style memory
mapped accesses (as explained in the PCI specs and any good book about PCI).
Gabriel can tell you more for sure.

> pcibase = (char *) mmap(..., PCI_BASE);  /* Just to show that its mmaped */
> gd->pci04 = 0x03000000;   /* enable memory and I/O accesses */
> gd->pci10 = 0x00000000;
> *(pcibase + 1) = gd->pci04;    /* 0x80808004 = gd->pci04? */
> *(pcibase + 4) = gd->pci10;    /* 0x80808010 = gd->pci10? */

pci04 is the PCI_COMMAND register. Writing 0x03000000 to it makes the Cirrus
Logic chip listen to accesses to its memory and I/O spaces.

pci10 is PCI_BASE_ADDRESS_0, the register that defines where the base address
of the first memory space is located. Hmm, writing 0 to it puts it at address
zero. Weird... On my CHRP box, all PCI memory spaces are located at addresses
0xc0000000 and up. PReP is different. Gabriel? Cort?

More info in <linux/pci.h>

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: ioremap and related

[Gabriel Paubert]

On Wed, 16 Dec 1998, Geert Uytterhoeven wrote:

> 
> On Mon, 14 Dec 1998, Jeff Rugen wrote:
> > I have a few questions related to the ioremap function and some related
> > ones.
> > 
> > First, is ioremap the kernel equivalent of using mmap?  I'm working on the
> 
> Yes. ioremap() takes a physical address and size, and maps that block into
> kernel space.

That's a problem for PreP machines, where the contents of the PCI base
address registers are offsetted by the brige. Something has to be done
about it, but I have no clear idea of how to do it. Maybe the simplest
thing would be to put the processor physical address at which it appears
in the pci_device structure, that's a simple hack to pcibios_fixup.

Then I don't have to touch ioremap ! (Well I want to change ioremap
anywway it so that if you use it to access a legacy ISA device, it will
add isa_mem_base to the address before mapping). And also that it won't
allocate kernel vm if the area is already mapped with a BAT... 

Comments, criticism (but not flames) and especially better ideas
welcome...

> 
> > clgenfb device for LinuxPPC on a Motorola Powerstack, and I'm currently
> > thinking my problems are coming from setting up the framebuffer memory and
> > PCI stuff.  I have the source for Xbh, and it uses mmap() to map the I/O
> > registers, video memory, and PCI memory (not sure what the third is for, but
> > I have a question related to that below).
> > 
> > Now, in the clgenfb driver, it doesn't seem to like me using ioremap to set
> > up the registers for the Cirrus chip -- if I hard-code the registers to be
> > relative to 0x80000000, everything works fine (this is the memory location
> > mmaped in in Xbh server), but if I use ioremap, it doesn't work.
> > (By working, I mean it sets the video mode and sets/reads the color
> > registers... not working means I get a panic when starting to
> > initizliaze the hardware and can't detect the video memory size). 

The registers in the I/O area should be accessed with in[bwl]/out[bwl], or
am I missing something ? 

> > 
> > However, it seems I get a little farther if I ioremap video memory (mmapped
> > from 0xC0000000 in Xbh) than if I don't -- though the program crashes in
> > either case.  I'm also trying to use other framebuffer devices as reference,
> > but I'm not as familiar with them.
> > 
> > In addition, when I use ioremap for video memory, I get the following memory
> > locations in pointers:
> > video_phys = 0xc0000000, video_base = 0xc8000000
> > where video_phys is the physical address and video_base is the ioremapped.
> 
> OK.

Reasonable, but read below. 
> 
> > However, when I use phys_to_virt and virt_to_phys, I get strange values
> > (maybe its related to how much actual memory I have -- 96MB -- some bits may
> > not be decoded.)
> > phys_to_virt(video_phys) = 0x80000000
> > virt_to_phys(video_base) = 0x08000000
> > 
> > I expected the same numbers as above, but don't completely understand how
> > the functions work yet.
> 
> phys_to_virt() and virt_to_phys() don't work that well on MMIO. I was told
> they're for real memory only.

Indeed. 

> That's why most frame buffer devices remember both the physical address (as
> passed to ioremap()) and the virtual address (as returned by ioremap()).
> 
> > Finally, in Xbh, they do the following code with PCI stuff -- but I don't
> > really know what they're doing and was wondering if someone could explain it
> > in a sentence or two and indicate a good reference to look at to understand
> > it better (online if possible).  An equivalent that you would use in kernel
> > code would be cool too, but I don't expect that.  ;-)
> > 
> > #define PCI_BASE   ((volatile unsigned long *) 0x80808000)
> 
> These are accesses to the PCI configuration space, using PReP style memory
> mapped accesses (as explained in the PCI specs and any good book about PCI).
> Gabriel can tell you more for sure.

Well, my boards don't support this config access method. Which is probably
deprecated since it is very limited (only bus 0, so no bridges). It is
explained in the MPC105 manual (and MPC106 also AFAIR), available on
Motorola's website. 

> 
> > pcibase = (char *) mmap(..., PCI_BASE);  /* Just to show that its mmaped */
> > gd->pci04 = 0x03000000;   /* enable memory and I/O accesses */
> > gd->pci10 = 0x00000000;
> > *(pcibase + 1) = gd->pci04;    /* 0x80808004 = gd->pci04? */
> > *(pcibase + 4) = gd->pci10;    /* 0x80808010 = gd->pci10? */
> 
> pci04 is the PCI_COMMAND register. Writing 0x03000000 to it makes the Cirrus
> Logic chip listen to accesses to its memory and I/O spaces.
> 
> pci10 is PCI_BASE_ADDRESS_0, the register that defines where the base address
> of the first memory space is located. Hmm, writing 0 to it puts it at address
> zero. Weird... On my CHRP box, all PCI memory spaces are located at addresses
> 0xc0000000 and up. PReP is different. Gabriel? Cort?

Yeah, but on PreP the MMIO addresses are offset by 0xc0000000 by the host
bridge, so that if this register is set to 0, the processor has to
generate physical address 0xc0000000 to access it, so you have to ioremap
at 0xc0000000 (unless we modify ioremap, but I'm still wondering as to
what the right way to do it is, as said earlier).

Howvever, setting it to zero is bad for at least 2 reasons:

- it may conflict with some ISA devices, making them inaccessible because
of the subtractive decoding nature of the PCI<->ISA bridge.

- PCI specifications 2.1 state that setting a base address register to 0 
disables the corresponding decoder. Many devices are buggy in this
respect however.

	Greetings,
	Gabriel.



[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: ioremap and related

[Jeff Rugen]

On Fri, 18 Dec 1998, Gabriel Paubert wrote:

> > > Now, in the clgenfb driver, it doesn't seem to like me using ioremap to set
> > > up the registers for the Cirrus chip -- if I hard-code the registers to be
> > > relative to 0x80000000, everything works fine (this is the memory location
> > > mmaped in in Xbh server), but if I use ioremap, it doesn't work.
> > > (By working, I mean it sets the video mode and sets/reads the color
> > > registers... not working means I get a panic when starting to
> > > initizliaze the hardware and can't detect the video memory size). 
> 
> The registers in the I/O area should be accessed with in[bwl]/out[bwl], or
> am I missing something ? 

I've gotten this working to some extent (on my computer anyway) so I'm
mainly looking for understanding.  I'm using in[bw]/out[bw] to access the
registers in the I/O area.  What's confusing is I have to ioremap the memory
map area (at 0xC0000000) but I don't have to ioremap the I/O area (at
0x80000000).  I don't understand why though.

For that matter, once I ioremap the memory map area, I have to use
virt_to_phys() to convert it to a memory location that I save to give back
to the framebuffer code, just because the framebuffer code uses
phys_to_virt() to convert it back to a value it can use.  None of the other
framebuffer drivers need to do this, so it feels like a hack.

<snip>

> > pci10 is PCI_BASE_ADDRESS_0, the register that defines where the base address
> > of the first memory space is located. Hmm, writing 0 to it puts it at address
> > zero. Weird... On my CHRP box, all PCI memory spaces are located at addresses
> > 0xc0000000 and up. PReP is different. Gabriel? Cort?
> 
> Yeah, but on PreP the MMIO addresses are offset by 0xc0000000 by the host
> bridge, so that if this register is set to 0, the processor has to
> generate physical address 0xc0000000 to access it, so you have to ioremap
> at 0xc0000000 (unless we modify ioremap, but I'm still wondering as to
> what the right way to do it is, as said earlier).
> 
> Howvever, setting it to zero is bad for at least 2 reasons:
> 
> - it may conflict with some ISA devices, making them inaccessible because
> of the subtractive decoding nature of the PCI<->ISA bridge.
> 
> - PCI specifications 2.1 state that setting a base address register to 0 
> disables the corresponding decoder. Many devices are buggy in this
> respect however.
> 

I'm currently using pcibios_(write|read)_config_dword to do the above.  In
the PCI structure, base_address[0] is already set to 0 however, so possibly
I don't need to touch pci10 -- which may make the code work on more machines
if I understand the rest of what was said :-)

Would it be worth my posting the snippet of code that sets up the memory
locations of the I/O registers and memory map and enables PCI access to
both?

----------------------------------------------------------------------------
Jeff Rugen                      jrugen@primenet.com

...Had this been an actual emergency, we would have fled in terror, and you 
would not have been informed.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

ns16550.[hc]

[Jeff Rugen]

I'm building on a Motorola PowerStack from the vger tree.  The Makefile and
misc.c in arch/ppc/boot are looking for the files ns16550.h and ns16550.c,
but they don't seem to be in vger.  (I'm compiling with serial console on
and a non-MTX board -- I think those are the conditional flags that
select/deselect it).  Should those files be in vger or do I have to get them
elsewhere, or do I have a problem with my cvs setup or something?  I've did
a cvs update -A -d yesterday.


----------------------------------------------------------------------------
Jeff Rugen                      jrugen@primenet.com

..Had this been an actual emergency, we would have fled in terror, and you 
would not have been informed.


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: ioremap and related

[Christoph Nadig]

Hello Jeff,

> Finally, in Xbh, they do the following code with PCI stuff -- but I don't
> really know what they're doing and was wondering if someone could explain it
> in a sentence or two and indicate a good reference to look at to understand
> it better (online if possible).  An equivalent that you would use in kernel
> code would be cool too, but I don't expect that.  ;-)

This code configures the PCI interface of the chip.It basically make the whole
video memory available
directly (in contrast to the "normal" VGA way, where only
a selectable 64K window can be accessed) and sets the
physical address to 0xC0000000.
Unfortunately the manual is no longer available online, as
this chip was phased quite a while ago.

I can fax you the respective pages of my manual,
if you like (send your number to christoph.nadig@stest.ch)

Cheers,
Christoph

--
Christoph Nadig                | mailto:christoph.nadig@stest.ch
Switching Test Solutions AG    | web   :http://www.stest.com
a Wandel & Goltermann Company  | Phone : +41 1 454-6726
Friesenbergstr. 75             | FAX   : +41 1 454-6605
CH-8055 Zurich                 |




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]