ioremap() on ISA memory space

ioremap() on ISA memory space

[Geert Uytterhoeven]

I found one reason why current kernels don't work on my LongTrail: my NVRAM is
in ISA memory space. When the kernel tries to ioremap() it in
pmac_nvram_init(), I get

    __ioremap(): phys addr e0000 is RAM lr c000e43c

and ioremap() returns NULL, causing all later accesses to NVRAM (e.g. in atyfb)
to fail due to NULL pointer dereferences.

Do all CHRP boxes have NVRAM in ISA memory space? The comment (by Corey) near
the call to pmac_nvram_init() in chrp_init2() already wonders whether
pmac_nvram_init() should be called or not.

Besides, I'd say one must call ioremap() to access ISA memory space anyway, so
it sounds like a bug in the memory management subsystem to me.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ioremap() on ISA memory space

[Gabriel Paubert]

On Tue, 8 Jun 1999, Geert Uytterhoeven wrote:

> 
> 
> I found one reason why current kernels don't work on my LongTrail: my NVRAM is
> in ISA memory space. When the kernel tries to ioremap() it in
> pmac_nvram_init(), I get
> 
>     __ioremap(): phys addr e0000 is RAM lr c000e43c
> 
> and ioremap() returns NULL, causing all later accesses to NVRAM (e.g. in atyfb)
> to fail due to NULL pointer dereferences.
> 
> Do all CHRP boxes have NVRAM in ISA memory space? The comment (by Corey) near
> the call to pmac_nvram_init() in chrp_init2() already wonders whether
> pmac_nvram_init() should be called or not.

I don't know, but according to M.Mares (the PCI guy), all addresses passed
to ioremap should be processor physical addresses. So you should modify
the call to ioremap to add the physical offset at which the ISA memory
space (address 0-16 Mb) appears on the PCI bus. 

The hacks done on the i386 port are not valid since on a standard PC
addresses from 640kB to 1Mb-64kB are directly forwarded to PCI/ISA.
On a PC, the addresses on both sides of the host bridge are always the
same. It is simply not possible to stick to this rule when you want to
have all physical memory contiguous and starting at address 0.

The 8088 is still going to bite us for some time with these ambiguous
addresses and DMA problems :-(.  

> Besides, I'd say one must call ioremap() to access ISA memory space anyway, so
> it sounds like a bug in the memory management subsystem to me.

Indeed (note that Linus indicated that ioremap for ISA memory space would 
be compulsory in 2.3 even on i386), but this is not necessarily a mm bug
IMHO. It would be better to define a macro that conditionally adds a
platform dependant offset for addresses < 16 Mb (I've heard that
ISA_MEM_BASE has been killed, and I disagree just because of this kind
of things).

I would rather use ioremap(dev->base_address[n],...) for standard PCI
devices and ioremap(ISA_PHYSICAL_ADDRESS(xxx),...) for devices which might
be on ISA with: 

#define ISA_PHYSICAL_ADDRESS(x) \ 
(((x)<0x1000000) ? ((x)+ISA_PHYSICAL_BASE) : (x))

where ISA_PHYSICAL_BASE is a boot time constant (0xfd000000 on MPC106,
don't know on others). 

	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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ioremap() on ISA memory space

[Daniel Jacobowitz]

On Tue, Jun 08, 1999 at 09:08:04PM +0200, Gabriel Paubert wrote:
> be compulsory in 2.3 even on i386), but this is not necessarily a mm bug
> IMHO. It would be better to define a macro that conditionally adds a
> platform dependant offset for addresses < 16 Mb (I've heard that
> ISA_MEM_BASE has been killed, and I disagree just because of this kind
> of things).
> 
> I would rather use ioremap(dev->base_address[n],...) for standard PCI
> devices and ioremap(ISA_PHYSICAL_ADDRESS(xxx),...) for devices which might
> be on ISA with: 
> 
> #define ISA_PHYSICAL_ADDRESS(x) \ 
> (((x)<0x1000000) ? ((x)+ISA_PHYSICAL_BASE) : (x))
> 
> where ISA_PHYSICAL_BASE is a boot time constant (0xfd000000 on MPC106,
> don't know on others). 


Incidentally, and somewhat related to this:

When I was hacking on tulip.c, I wanted to use tulip-daig to get the
state of the card.  But it uses inl/outl, and on powerpc these have a
kernel private variable (isa_io_base) in their macro expansion.  Is
there any way to make the PCI space available to userland on powerpc,
as iopl() and inb/outb can on x86?


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ioremap() on ISA memory space

[Paul Mackerras]

Daniel Jacobowitz <drow@false.org> wrote:

> When I was hacking on tulip.c, I wanted to use tulip-daig to get the
> state of the card.  But it uses inl/outl, and on powerpc these have a
> kernel private variable (isa_io_base) in their macro expansion.  Is
> there any way to make the PCI space available to userland on powerpc,
> as iopl() and inb/outb can on x86?

You have to open /dev/mem and do a mmap of the physical pages for the
PCI I/O space.  You would then need to have a variable called
isa_io_base and put the address you get back from mmap into it.
PCI I/O space is usually at 0xf2000000 on older powermacs.  If you
want to get fancy, you can wander through /proc/device-tree looking
for the primary PCI bridge and use that to work out where the I/O
space is.

Paul.

[[ 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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ioremap() on ISA memory space

[Geert Uytterhoeven]

On Tue, 8 Jun 1999, Daniel Jacobowitz wrote:
> On Tue, Jun 08, 1999 at 09:08:04PM +0200, Gabriel Paubert wrote:
> > be compulsory in 2.3 even on i386), but this is not necessarily a mm bug
> > IMHO. It would be better to define a macro that conditionally adds a
> > platform dependant offset for addresses < 16 Mb (I've heard that
> > ISA_MEM_BASE has been killed, and I disagree just because of this kind
> > of things).
> > 
> > I would rather use ioremap(dev->base_address[n],...) for standard PCI
> > devices and ioremap(ISA_PHYSICAL_ADDRESS(xxx),...) for devices which might
> > be on ISA with: 
> > 
> > #define ISA_PHYSICAL_ADDRESS(x) \ 
> > (((x)<0x1000000) ? ((x)+ISA_PHYSICAL_BASE) : (x))
> > 
> > where ISA_PHYSICAL_BASE is a boot time constant (0xfd000000 on MPC106,
> > don't know on others). 
> 
> Incidentally, and somewhat related to this:
> 
> When I was hacking on tulip.c, I wanted to use tulip-daig to get the
> state of the card.  But it uses inl/outl, and on powerpc these have a
> kernel private variable (isa_io_base) in their macro expansion.  Is
> there any way to make the PCI space available to userland on powerpc,
> as iopl() and inb/outb can on x86?

You have to mmap() /dev/mem and store the result in a variable called
isa_io_base first. But the address region you have to map depends on the
machine type :-(

Example: http://www.cs.kuleuven.ac.be/~geert/PowerPC/sio.c

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ioremap() on ISA memory space

[Geert Uytterhoeven]

On Tue, 8 Jun 1999, Gabriel Paubert wrote:
> On Tue, 8 Jun 1999, Geert Uytterhoeven wrote:
> > I found one reason why current kernels don't work on my LongTrail: my NVRAM is
> > in ISA memory space. When the kernel tries to ioremap() it in
> > pmac_nvram_init(), I get
> > 
> >     __ioremap(): phys addr e0000 is RAM lr c000e43c
> > 
> > and ioremap() returns NULL, causing all later accesses to NVRAM (e.g. in atyfb)
> > to fail due to NULL pointer dereferences.
> > 
> > Do all CHRP boxes have NVRAM in ISA memory space? The comment (by Corey) near
> > the call to pmac_nvram_init() in chrp_init2() already wonders whether
> > pmac_nvram_init() should be called or not.
> 
> I don't know, but according to M.Mares (the PCI guy), all addresses passed
> to ioremap should be processor physical addresses. So you should modify
> the call to ioremap to add the physical offset at which the ISA memory
> space (address 0-16 Mb) appears on the PCI bus. 

Oops, you're right (in my case that's an offset of 0xf7000000). Hence we have
to `fix up' the OF device tree first...

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: ioremap() on ISA memory space

[Geert Uytterhoeven]

On Wed, 9 Jun 1999, Geert Uytterhoeven wrote:
> On Tue, 8 Jun 1999, Gabriel Paubert wrote:
> > On Tue, 8 Jun 1999, Geert Uytterhoeven wrote:
> > > I found one reason why current kernels don't work on my LongTrail: my NVRAM is
> > > in ISA memory space. When the kernel tries to ioremap() it in
> > > pmac_nvram_init(), I get
> > > 
> > >     __ioremap(): phys addr e0000 is RAM lr c000e43c
> > > 
> > > and ioremap() returns NULL, causing all later accesses to NVRAM (e.g. in atyfb)
> > > to fail due to NULL pointer dereferences.
> > > 
> > > Do all CHRP boxes have NVRAM in ISA memory space? The comment (by Corey) near
> > > the call to pmac_nvram_init() in chrp_init2() already wonders whether
> > > pmac_nvram_init() should be called or not.
> > 
> > I don't know, but according to M.Mares (the PCI guy), all addresses passed
> > to ioremap should be processor physical addresses. So you should modify
> > the call to ioremap to add the physical offset at which the ISA memory
> > space (address 0-16 Mb) appears on the PCI bus. 
> 
> Oops, you're right (in my case that's an offset of 0xf7000000). Hence we have
> to `fix up' the OF device tree first...

`nvram' is actually `/pci/isa@1/nvram@me0000' (note the `m' after the `@'), so
the device tree does know it's ISA _memory_ space. But this isn't reflected in
the properties of the node:

| reg                      00000000 000e0000 00008000
| device_type              nvram
| name                     nvram

Well, since the call to ioremap() is protected by a test for CHRP:

        if (_machine == _MACH_chrp && nvram_naddrs == 1) {
                nvram_data = ioremap(dp->addrs[0].address, dp->addrs[0].size);
                nvram_mult = 1;
        } else ...

I think it's safe to always add the ISA memory base offset there.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]