<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
&nbsp;&nbsp;&nbsp; Konstantin, Martin,<br>
<br>
&nbsp;&nbsp;&nbsp; First, I am not sure that our discussion is in the scope of the
list, but the others didn't complain still...<br>
<br>
&nbsp;&nbsp;&nbsp; I gave a look at the VITA publications about the CR/CSR.<br>
<br>
&nbsp;&nbsp;&nbsp; CR/CSR was introduced in the VME64 standard. These registers are
dedicated to inform the user of the board's identity and capabilities
and perform some settings. they belong to a space different of the
"logical" address spaces (A16/A24/A32/A64). The base address of the
"logical" address spaces was traditionally set by hexadecimal switches.
VME64 allows to set it by writing registers in the CR/CSR space.
Obviously, this should not relocate the CR/CSR space itself. VME64 does
not specify how the base address of the CR/CSR space is set.<br>
<br>
&nbsp;&nbsp;&nbsp; VME64 was a transitional standard and this uncertainty has been
solved by VME64x which specifies that this base address is coded on the
backplane connectors this is what makes it a "geographical" address
space (a term derived from FastBus). It allows an application to
discover which board is present in which slot. For this to work, you
should have a VME64x crate and a VME64x board, with the new connector
type for P1 and P2.<br>
<br>
&nbsp;&nbsp;&nbsp; To allow the use of CR/CSR in non-VME64x devices and/or crates, the
CR/CSR base address can sometimes be set by switches (not the same
switches as the other spaces). According to what Konstantin is saying,
his board also maps the CR/CSR to the A16 address space, which seems
strange to me. Have you an online documentation of the board?<br>
<br>
&nbsp;&nbsp;&nbsp; Now, for the ioctl problem, Konstantin, did you try to set
xlatedAddrL to zero. The Tsio148, and therefore the driver, enforce
alignment on&nbsp; rather big blocks and maybe misalignment is the cause of
the "invalid argument" error. I see no reason not to map the entire
A16, A24 or CR/CSR spaces. For the others, of course, you are limited
by the size of the cpu's address space.<br>
<br>
&nbsp;&nbsp;&nbsp; I will eventually try to reproduce your ioctl problem next week.
Hopping you will solve it before<span class="moz-smiley-s1"><span> :-) </span></span>.<br>
<br>
&nbsp;&nbsp;&nbsp; Best regards. Didier<br>
<br>
Konstantin Boyanov said:
<blockquote
 cite="mid929bf310703290313o234a47f9gbf9c5083fc23e45e@mail.gmail.com"
 type="cite">Hi again,<br>
  <br>
Thank you once again for presenting the VME world to me :)<br>
  <br>
&gt;Looks like you're reading something. &nbsp;Address 0x10100000 is larger
than<br>
&gt;a 24 bit address. &nbsp;Perhaps you should be using A32 transfers
instead of
  <br>
&gt;A24?<br>
  <br>
No, no, I need to do A16 access, thats the only way to read the control
registers. Form here comes also my confusion - I thought that when I'm
reading CS/CSR register I need to do it in CSR address space. So no
algorithms for geographical location of boards are needed in my case I
guess.
  <br>
Actually the base address of CSR on the board is 0xA000 (10100000 is
the first byte of the address selection in inary, shame on me :( ). But
when I try to configure it with outWinCfgADC.zlatedAddrL = 0xA000, when
I run the programm I get an errno 29 (Invalid argument) from ioctl().
In fact if I set the xlatedAddrL to some value smaller that 0x10000 I
get this error. Here's my most recent configuration:
  <br>
  <br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.windowNbr&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; = 0;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.windowEnable&nbsp; &nbsp; &nbsp; = 1;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.wrPostEnable &nbsp;&nbsp; &nbsp; = 0;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.userAccessType&nbsp; = VME_SUPER;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.dataAccessType&nbsp; = VME_DATA;
  <br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.windowSizeL&nbsp; &nbsp; &nbsp;&nbsp; = 0x10000;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.xferProtocol&nbsp; &nbsp; &nbsp; &nbsp;&nbsp; = VME_SCT;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.addrSpace &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; = VME_A16;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.maxDataWidth &nbsp;&nbsp;&nbsp; = VME_D16;<br>
&nbsp;&nbsp;&nbsp; outWinCfgADC.xlatedAddrL
&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; = 0x10000000;<br>
  <br>
I think that 0x10000 for window size is big enough to encompass the
whole A16 addressable space. With the 0x10000000 xlatedAddr I get no
errors and read the desired registers when I increment this address to
0x1000A000. But nevertheless it seems strange to me that the device
does not accept xlatedAddr lower that 0x10000. Maybe its due to the
configuration of the VME controller?
  <br>
  <br>
Best regards,<br>
Konstantin<br>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Linuxppc-embedded mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Linuxppc-embedded@ozlabs.org">Linuxppc-embedded@ozlabs.org</a>
<a class="moz-txt-link-freetext" href="https://ozlabs.org/mailman/listinfo/linuxppc-embedded">https://ozlabs.org/mailman/listinfo/linuxppc-embedded</a></pre>
</blockquote>
<br>
</body>
</html>