RE: access memory mapped registers

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 [off-list ref]
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/

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

we had a similar problem with our custom 405 board and we solved it this way:

- making a device driver which does the basic stuff like accessing the GPIOs
  in the proper way.
- defining an ioctl interface that allows any application to download the
  FPGA code.
- creating an user space application which takes a filename as a parameter and
  sends it via the ioctls to the device driver. (we called it loadfpga)

The ioctl interface is pretty simple. It only needs just one action code
(FpgaProg) with a block of at most 4k bytes as data and an additional option
field showing the driver whether this block of data is the first one and/or the
last one.

The driver now does just some simple actions like this:
 - if this is the first block do the proper initilization of the downloading
   (in our case we needed to initialize the GPIOs, puls the PROG and check the
    INIT signal)
 - for all blocks do the signaling via the GPIO bitwise (in our case set DIN
    for all bits and puls the CLK signal)
 - if this was the last block do the concluding actions (in our case do some
    CLK pulses and wait for the DONE signal and then take the chip out of reset)

The user space application is even simplier:
 - Read the binary file in 4k blocks
 - Issue an ioctl and set the bits signaling whether this block is the first
    and/or the last properly.

This concept may also work for your case.

Kind regards,
Georg


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