access memory mapped registers

access memory mapped registers

[Muaddi, Cecilia]

Hello,

This is probably one of those silly questions again, and I seem to be having
a lot of them lately.

I will like to access some memory mapped registers through user space
applications.
Do i just use the "mmap" function calls to map the physical memory to my
user space?
My BR/OR registers are set up properly to handle the addresses, but do i
need to configure
the kernel for those memory regions?

The address I am looking at is at physical location 0x60000000 and
0x40000000.  My RAM space is mapped to
virtual address starting at 0xc0000000 (where the RAM's physical address is
from 0x0 - 0x00ffffff)

THank you very much for your help

Cecilia

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

Re: access memory mapped registers

[Wolfgang Denk]

In message <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM> you wrote:
>
> I will like to access some memory mapped registers through user space
> applications.
> Do i just use the "mmap" function calls to map the physical memory to my
> user space?

You don't. Design a proper device driver interface instead.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.

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

RE: access memory mapped registers

[Kerl, John]

For what it's worth, I've done a couple of quick-and-dirty
devices, in the way you described (mmap from user space).
And you are right that (1) an app may not crash the kernel as
easily -- but remember that a root application can mmap
*anything*, and (2) you don't have to reboot the kernel to try a
code change.  Also (3) I found it easy to code, and (4) I didn't
have to mess with IRQs -- meaning that the person who wrote
the FPGA code had less work to do, & he was already pressed for
time.  (Also I've a "proper" device driver, but it was a very
simple one.)

For one project, the mmap worked fine.  For the other project,
it also worked OK (the demo ran, and the vendor was pleased,
and the project was done start-to-finish, PPC/Linux & FPGA/VHDL
etc., in a very short amount of time), but it made some coding
awkward, and it affected performance.  In particular, my
application was in a loop listening for one of four things:

*	Keystrokes at the console
*	A PF_UNIX (local) socket
*	A PF_INET (UDP)   socket
*	A packet received at my device (an FPGA)

Thanks to the design of Unix, I could select() for the
first three, and the OS would tell me when any of them
was ready.  But since I did the quick-and-dirty mmap()
thing for my FPGA, I had to poll it by reading the mmap.
So I ended up choosing which to service more quickly --
the longer I sat in select(), the less time between checks
to the FPGA, increasing latency there.  The less time I sat
in select(), the more CPU time I ate up, and also my latency
worsened for servicing network packets.

Wolfgang can no doubt give you many more reasons, perhaps
some philosophical, to do a "real" driver.  However, the above
example is a practical one -- performance.


-----Original Message-----
From: Muaddi, Cecilia [mailto:cecilia.muaddi@alloptic.com]
Sent: Thursday, January 09, 2003 5:06 PM
To: 'Wolfgang Denk'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: access memory mapped registers



Sorry, forgot to mentioned those devices are T1 framers, custom FPGA, and
ethernet switching chips.
Don't know if that makes any difference.

-Cecilia
-----Original Message-----
From: Muaddi, Cecilia
Sent: Thursday, January 09, 2003 4:04 PM
To: 'Wolfgang Denk'; Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: RE: access memory mapped registers


why would it be better to use the device driver than via the mmap from user
space?

one of my criteria was to make sure no software mistake will cause the
kernel to hang, as
in the case of vxWorks we are running.  So, if I implement my access to the
device
in the device driver, doesn't that means if there are problem with the
device driver
portion, i will cause the kernel to hang?  Furthermore, any enhancement to
the device
driver will require me to reinstall the kernel?  whereas if all my user
space
application handles the access to those devices, I can stop the user space
application,
update it with the new application without requiring the system to reboot?

Sorry if those sounded like silly questions.

Thanks

Cecilia

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, January 09, 2003 3:14 PM
To: Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: access memory mapped registers


In message <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM>
you wrote:
>
> I will like to access some memory mapped registers through user space
> applications.
> Do i just use the "mmap" function calls to map the physical memory to my
> user space?

You don't. Design a proper device driver interface instead.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.


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

Re: access memory mapped registers

[Wolfgang Denk]

In message <885489B3B89FB6449F93E525DF78777F06453E@srvnt506.ALLOPTIC.COM> you wrote:
> why would it be better to use the device driver than via the mmap from user
> space?

Reliability, robustnes, clean design, ...

Why do we have a separation into kernel and user space at all?

> one of my criteria was to make sure no software mistake will cause the
> kernel to hang, as
> in the case of vxWorks we are running.  So, if I implement my access to the

Then don't weaken the memory protection of the Unix design.

> device
> in the device driver, doesn't that means if there are problem with the
> device driver
> portion, i will cause the kernel to hang?  Furthermore, any enhancement to

Don't you think that an application process that  will  write  random
data to your hardware will have a much higher potential to cause harm
than  a  carefully designed, implementred, reviewed and tested device
driver?

> driver will require me to reinstall the kernel?  whereas if all my user
> space
> application handles the access to those devices, I can stop the user space
> application,
> update it with the new application without requiring the system to reboot?

You can dynamically load and unload device drivers.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Wish not to seem, but to be, the best."                  - Aeschylus

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

RE: access memory mapped registers

[Muaddi, Cecilia]

Given that, do you know what is the convention if I need to address the GPIO
pins in
the 860?   I have some FPGA which require me to download the FPGA code
and they are controlled via JTAG from my GPIO pins out of 860.  I can use
mmap to map the ppc 860 internal memory (the quick dirty way just to see if
works), or is there a driver already provided which will allow me to control
the GPIO pins from user application?

Thanks

Cecilia

-----Original Message-----
From: Kerl, John [mailto:John.Kerl@Avnet.com]
Sent: Thursday, January 09, 2003 4:19 PM
To: 'Muaddi, Cecilia'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: access memory mapped registers


For what it's worth, I've done a couple of quick-and-dirty
devices, in the way you described (mmap from user space).
And you are right that (1) an app may not crash the kernel as
easily -- but remember that a root application can mmap
*anything*, and (2) you don't have to reboot the kernel to try a
code change.  Also (3) I found it easy to code, and (4) I didn't
have to mess with IRQs -- meaning that the person who wrote
the FPGA code had less work to do, & he was already pressed for
time.  (Also I've a "proper" device driver, but it was a very
simple one.)

For one project, the mmap worked fine.  For the other project,
it also worked OK (the demo ran, and the vendor was pleased,
and the project was done start-to-finish, PPC/Linux & FPGA/VHDL
etc., in a very short amount of time), but it made some coding
awkward, and it affected performance.  In particular, my
application was in a loop listening for one of four things:

*	Keystrokes at the console
*	A PF_UNIX (local) socket
*	A PF_INET (UDP)   socket
*	A packet received at my device (an FPGA)

Thanks to the design of Unix, I could select() for the
first three, and the OS would tell me when any of them
was ready.  But since I did the quick-and-dirty mmap()
thing for my FPGA, I had to poll it by reading the mmap.
So I ended up choosing which to service more quickly --
the longer I sat in select(), the less time between checks
to the FPGA, increasing latency there.  The less time I sat
in select(), the more CPU time I ate up, and also my latency
worsened for servicing network packets.

Wolfgang can no doubt give you many more reasons, perhaps
some philosophical, to do a "real" driver.  However, the above
example is a practical one -- performance.


-----Original Message-----
From: Muaddi, Cecilia [mailto:cecilia.muaddi@alloptic.com]
Sent: Thursday, January 09, 2003 5:06 PM
To: 'Wolfgang Denk'
Cc: 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: access memory mapped registers



Sorry, forgot to mentioned those devices are T1 framers, custom FPGA, and
ethernet switching chips.
Don't know if that makes any difference.

-Cecilia
-----Original Message-----
From: Muaddi, Cecilia
Sent: Thursday, January 09, 2003 4:04 PM
To: 'Wolfgang Denk'; Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: RE: access memory mapped registers


why would it be better to use the device driver than via the mmap from user
space?

one of my criteria was to make sure no software mistake will cause the
kernel to hang, as
in the case of vxWorks we are running.  So, if I implement my access to the
device
in the device driver, doesn't that means if there are problem with the
device driver
portion, i will cause the kernel to hang?  Furthermore, any enhancement to
the device
driver will require me to reinstall the kernel?  whereas if all my user
space
application handles the access to those devices, I can stop the user space
application,
update it with the new application without requiring the system to reboot?

Sorry if those sounded like silly questions.

Thanks

Cecilia

-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, January 09, 2003 3:14 PM
To: Muaddi, Cecilia
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: access memory mapped registers


In message <885489B3B89FB6449F93E525DF78777F06453B@srvnt506.ALLOPTIC.COM>
you wrote:
>
> I will like to access some memory mapped registers through user space
> applications.
> Do i just use the "mmap" function calls to map the physical memory to my
> user space?

You don't. Design a proper device driver interface instead.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.


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

Re: access memory mapped registers

[Wolfgang Denk]

In message <885489B3B89FB6449F93E525DF78777F064541@srvnt506.ALLOPTIC.COM> you wrote:
>
> Given that, do you know what is the convention if I need to address the GPIO
> pins in
> the 860?   I have some FPGA which require me to download the FPGA code
> and they are controlled via JTAG from my GPIO pins out of 860.  I can use
> mmap to map the ppc 860 internal memory (the quick dirty way just to see if
> works), or is there a driver already provided which will allow me to control
> the GPIO pins from user application?

There is no such driver, and there cannot be any such generic driver,
as the usage of the port pins is different for  each  board.  And  it
would  be  a  very  bad idea to allow any user to mess with important
things. You can even ruin hardware that way.

Do yourself a favour and write a device driver that does  what  needs
to be done.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There is nothing in this world constant but inconstancy.      - Swift

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

Re: access memory mapped registers

[Wolfgang Denk]

In message <885489B3B89FB6449F93E525DF78777F064542@srvnt506.ALLOPTIC.COM> you wrote:
>
> I can see if I mmap the internal 860 CPU registers, and screw up that, I
> will
> definitely screw up the system, and require it to be reboot.  BUt if the
> hardware we are mapping is outside the CPU internal memory and outside the
> RAM,
> shouldn't the failure be limited to the user application only then?

No. For example, assume there is a port pin  which  is  meant  as  an
input,  and  the  signal  is  driven from external hardware. Now your
application program by mistake re-programs this pin  as  output.  You
may smoke your board this way.

> only the memory regions that is mapped to the ethernet switching chip,
> even if I screw up on the hardware setup, shouldn't my kernel still be
> protected?  At most, the application faults and I should be able to restart
> the application without rebooting the system?

There is a simple rule: if you open backdoors in a secure system  the
result  is  an insecure system. Write clean code.


There is many things you have to keep in mind:

* Functionality: you cannot process interrupts in user space

* Performance: how do you synchronize your accesses to the  hardware?

* Communication: How do you know when data has been processed, or has
  become available, or stable, or ...?

* Tricky things: What will the caches in  your  system  do  when  the
  application  accesses  the  hardware?  How will you address memory?
  Remember that there are systems where  a  32  bit  address  is  not
  sufficient any more...

etc. etc.

Write clean code.



Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Life is a game. Money is how we keep score.              - Ted Turner

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

RE: access memory mapped registers

[Kenneth Johansson]

On Fri, 2003-01-10 at 01:46, Muaddi, Cecilia wrote:
>
> I can see if I mmap the internal 860 CPU registers, and screw up that, I
> will
> definitely screw up the system, and require it to be reboot.  BUt if the
> hardware we are mapping is outside the CPU internal memory and outside the
> RAM,
> shouldn't the failure be limited to the user application only then?
>
> for example, an ethernet switch chip in a layer 2 router is controlled
> by the PPC 860.  THe 860 is only used for configuration (not in the
> datapath)
> if I mmap
> only the memory regions that is mapped to the ethernet switching chip,
> even if I screw up on the hardware setup, shouldn't my kernel still be
> protected?  At most, the application faults and I should be able to restart
> the application without rebooting the system?
>

Yes you are safe. There is nothing wrong with doing things in userspace
if you can. I have designed our system like this and have a very simple
IRQ driver that signals to userspace that an interrupt is pending to get
response time down and avoid polling but that is the only part I have in
the kernel.

The only reason to put anything into the kernel is speed and protection
so the first option should be to try to do it in userspace failing that
move it or parts to the kernel.


--
Kenneth Johansson
Ericsson AB                       Tel: +46 8 404 71 83
Tellusborgsvägen  94              Fax: +46 8 404 72 72
126 25 Stockholm                  ken@switchboard.ericsson.se


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