Reading and writing from/to VME device

[Didier Kryn]

    Konstantin, Martin,

    First, I am not sure that our discussion is in the scope of the 
list, but the others didn't complain still...

    I gave a look at the VITA publications about the CR/CSR.

    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.

    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.

    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?

    Now, for the ioctl problem, Konstantin, did you try to set 
xlatedAddrL to zero. The Tsio148, and therefore the driver, enforce 
alignment on  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.

    I will eventually try to reproduce your ioctl problem next week. 
Hopping you will solve it before :-) .

    Best regards. Didier

Konstantin Boyanov said:
> Hi again,
>
> Thank you once again for presenting the VME world to me :)
>
> >Looks like you're reading something.  Address 0x10100000 is larger than
> >a 24 bit address.  Perhaps you should be using A32 transfers instead of
> >A24?
>
> 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.
> 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:
>
>     outWinCfgADC.windowNbr           = 0;
>     outWinCfgADC.windowEnable      = 1;
>     outWinCfgADC.wrPostEnable      = 0;
>     outWinCfgADC.userAccessType  = VME_SUPER;
>     outWinCfgADC.dataAccessType  = VME_DATA;
>     outWinCfgADC.windowSizeL       = 0x10000;
>     outWinCfgADC.xferProtocol         = VME_SCT;
>     outWinCfgADC.addrSpace           = VME_A16;
>     outWinCfgADC.maxDataWidth     = VME_D16;
>     outWinCfgADC.xlatedAddrL          = 0x10000000;
>
> 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?
>
> Best regards,
> Konstantin
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070330/99d1a21d/attachment.htm