Hi Martyn,
It turns out that my SBC was configured as a system controller...
The result: it allowed access to the bus, where it shouldn't.
This way, 2 VME-boards were simultaneously modifying the address-lines,
causing a corrupt VME-address, resulting in a BERR bus error.
Kind regards,
& many thanks for your assistance & the hint regarding the system controller !
Steven De Roo
(PS: I have some questions about ROR/RWD, but will post these in another topic)
--------------------------------------------------------------------------------
On 07/05/13 10:54, Martyn Welch wrote:
> On 06/05/13 09:45, De Roo, Steven wrote:
>> Hi all,
>>
>> I'm running OpenSuSE 12.3, kernel 3.7.
>>
>
> I'm not aware of any changes between 3.7 and 3.9 that would affect the
> behaviour of the driver (mainly cosmetic changes), so I'm not sure
> it's worth trying 3.9...
>
>> I found out that the problem occurs when there is another card in the
>> VME-crate that performs a lot of writes in the memory-region I'm reading in my example.
>> ('a lot of' = each millisecond, the first 64 bytes get updated).
>>
>> I've already added a sleep to the loop in my example, ranging from 20
>> milliseconds to a whole second, and it's just a matter of time...
>> Sometimes, I get the freeze after 50 loops, sometimes after 2000.
>>
>> When I disable the VME-card that writes data to this region, my
>> example program keeps running flawlessly...
>> Can 'concurrent' access to the same memory region cause such a nasty result ?
>>
>
> The VME bus only allows one device to be using the data bus at a time.
> There is (in the case of the tsi148 and the ca91cx42 at least)
> hardware based arbitration of access to the bus, co-ordinated by the system controller.
>
> I have 3 boards here, ones acting as a slave, one's reading as before
> but reading from offset 0 and the command is run as:
>
> count=0 && while [[ $count -lt 100000 ]]; do ./test_extend; let
> count=$count+1; done
>
> (As the test code is looping internally 100 times, this represents
> some 10000000 read cycles...)
>
> It's been running for a good 5 minutes fine so far (I guess that's at
> least 2000 read cycles) and it hasn't failed yet...
>
Hmm, forgot to say, I have a 3rd board looping writing 64-bytes from a buffer pre-populated from "/dev/urandom", with a 1000 uS delay between writes.
Still running fine.
Martyn
> Are all the devices in your system SBCs (do all the boards access the
> VME bus via a tsi148)?
>
> Martyn
>
>> Kind regards,
>> Steven
>>
>>
>> ---------------------------------------------------------------------
>> -----------
>>
>> Hi Steven,
>>
>> I have run this test up on a pair of boards I have access to. I had to declare the loop variable, but other than that it seems to be running fine here (I'm testing this on the head of the staging tree[1]):
>>
>> root@ge-xvb601:~/vme_test# uname -r
>> 3.9.0
>> root@ge-xvb601:~/vme_test# gcc -o test_extended test_extended.c
>> root@ge-xvb601:~/vme_test# ./test_extended > test.txt
>> root@ge-xvb601:~/vme_test# wc -l test.txt 900 test.txt
>> root@ge-xvb601:~/vme_test# tail test.txt
>> 0038: ff ff df ff df ff ff ff
>>
>> 0000: ff ff ff fb ff f5 ff ff
>> 0008: ff ff ff ff 7f ff ff ff
>> 0010: ff ff df df be fb ff fe
>> 0018: ff f7 ff f7 7f ea ff ff
>> 0020: ff ef ff ff d8 ee ff ff
>> 0028: ff ff ff ff 7e f7 ff f7
>> 0030: ff ff 7b 6e 5d df ff ff
>> 0038: ff ff df ff df ff ff ff
>> root@ge-xvb601:~/vme_test#
>>
>> Which version of kernel are you running this on?
>>
>> Martyn
>>
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
>>
>> On 02/05/13 09:33, De Roo, Steven wrote:
>>> Dear all,
>>>
>>> I've been trying to access the VME-bus using a Xembedded XVME-6300
>>> board (with TSI-148 chipset) and the vme_user module from Martyn, with success.
>>> (Thanks to Martyn for an easy demo program).
>>>
>>> I've modified the code (see below) to...
>>> - use A_32/D_32
>>> - use 0x8BB00000 as base address
>>> - read data at an offset 0x8400 from this address
>>> - do a read of 6400 bytes instead of 512 bytes This seems to be
>>> working perfect (another VME-card writes a recognizable pattern at
>>> the above address, and I can see it using the printf-statements).
>>>
>>> HOWEVER:
>>> When I do this read in a loop (eg. 100 times), then my whole system
>>> freezes/hangs after about 50 times, and I have to power off/power on
>>> the machine...
>>>
>>> Does anybody have an idea what's going wrong ?
>>> Can I activate something to find out the problem ?
>>>
>>> Kind regards,
>>> Steven De Roo
>>>
>>> --------------------------------------------------------------------
>>> --
>>> ----------
>>>
>>> #define _XOPEN_SOURCE 500
>>> #define u32 unsigned int // Needed to add this line #include
>>> <linux/types.h> // Needed to add this line #include <stdio.h>
>>> #include <stdlib.h> #include <sys/ioctl.h> #include <sys/types.h>
>>> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h>
>>> #include "vme_user.h"
>>>
>>> int main(int argc, char *argv[])
>>> {
>>> int fd;
>>> int i;
>>> int retval;
>>> unsigned char data[6400];
>>>
>>> struct vme_master master;
>>>
>>> fd = open("/dev/bus/vme/m0", O_RDONLY);
>>> if (fd == -1) {
>>> perror("ERROR: Opening window device file");
>>> return 1;
>>> }
>>>
>>> master.enable = 1;
>>> master.vme_addr = 0x8BB00000;
>>> master.size = 0x10000;
>>> master.aspace = 4; // VME_A32
>>> master.cycle = 0x2000 | 0x8000; // user/data access
>>> master.dwidth = 4; // VME_D32
>>>
>>> retval = ioctl(fd, VME_SET_MASTER, &master);
>>> if (retval != 0) {
>>> printf("retval=%d\n", retval);
>>> perror("ERROR: Failed to configure window");
>>> return 1;
>>> }
>>> for (i=0; i<sizeof(data); i++) {
>>> data[i] = 0;
>>> }
>>>
>>> for (loop=0; loop<100; loop++)
>>> {
>>> retval = pread(fd, data, sizeof(data), 0x8400);
>>> if (retval < sizeof(data)) {
>>> printf("WARNING: Only read %d bytes", retval);
>>> }
>>>
>>> // Print first 64 bytes
>>> for(i=0; i<8*8; i++) {
>>> if (i % 8 == 0) {
>>> printf("\n""%4.4x: ", i);
>>> }
>>> printf("%2.2x ", data[i]);
>>> }
>>> printf("\n");
>>> }
>>>
>>> close(fd);
>>>
>>> return 0;
>>> }
>>>
>>
>>
>> --
>> Martyn Welch (Lead Software Engineer) | Registered in England and Wales
>> GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
>> T +44(0)1327322748 | Manchester, M2 3AB
>> E martyn.welch@xxxxxx | VAT:GB 927559189
>>
>
>
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@xxxxxx | VAT:GB 927559189
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
