Hi All, Thanks for your reply. I have been away the last few weeks. Dan, I am using 64 bit Debian 3.2.57. So I am not using the latest kernel. Would this be a problem? Martyn, I don't have a bus analyzer. I believe I have understood a few more things about my setup, but I still manage to hang the bus. I have the following questions for now: 1. Is there a way to find out if the tsi148 driver is working correctly? 2. Addressing?! I am still not clear on the addressing scheme. From the documentation of the slave (ZMI 4104 card) given it's set in slot 2 with Geographical Addressing enabled, the 24 bits of it's VME bus address are: A(23:20) -> 'b0000 [Board jumpers set to zero] A(19:15) -> 'b00010 [Geographical address set to 2, as the slave is in slot 2] A(14) -> 'b0 [0 if Geo Addressing enabled] AFAIK, this sets the base of the window to, 0x10000. Am I correct to assume this? > Does the board expect user/data cycles? The slave board responds to address modifier codes 0x39 (A24 non-privileged data access), and 0x3D (A24 supervisory data access), hence I set: master.cycle = 0x2000 | 0x8000; // user/data access Cheers! On Wed, Jun 11, 2014 at 10:36 AM, Martyn Welch <martyn.welch@xxxxxx> wrote: > Hi Maurice, > > > On 04/06/14 22:43, Maurice Moss wrote: >> >> Dear All, >> >> I came across the link here and decided to write to you, as I am >> facing a very similar problem: >> >> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-May/037941.html >> >> With the above linux, I have recompiled the kernel and booting the >> image with a vme_user.bus=0 vme_tsi148.geoid=1 vme_tsi148.err_chk=1 >> flags. I am just starting to get familiar with VME. >> >> Using XVME 6300 (sitting in Slot 1), I am trying to access a ZMI 4100 >> board (in slot 2, only 2 slots on the chassis whose back plane >> supports GA) via geographical addressing. > > > If the backplane supports geographical addressing, you don't need to set > geoid (unless your SBC doesn't support geoid that is). > > >> The ZMI board (supports >> only A24, D16/32, GA, NO CS/CSR). I pretty much have the same code as >> mentioned in the thread, however all I read are 0xff's and my system >> hangs every once in a while (needs hard reset). This makes debugging >> very hard. I am trying to read valid registers at a given offset (in >> this case 0x003C). >> >> My master struct is setup as below and I hope you can help me with the >> following questions: >> master.enable = 1; >> master.vme_addr = 0x10000; >> master.size = 0x10000; >> master.aspace = 2; // VME_A24 >> master.cycle = 0x2000 | 0x8000;// user/data access >> master.dwidth = 2; // 16 bit word access > > > Is this offset 0x003C in the VME address space or 0x1003C? You have the base > of the window set to 0x10000. > > Does the board expect user/data cycles? > > >> 0. I suspect my master struct is packed wrong. >> >> struct vme_master { >> int enable; /* State of Window */ >> unsigned long long vme_addr; /* Starting Address on the VMEbus >> */ >> unsigned long long size; /* Window Size */ >> vme_address_t aspace; /* Address Space */ >> vme_cycle_t cycle; /* Cycle properties */ >> vme_width_t dwidth; /* Maximum Data Width */ >> }; >> > > I'm not sure I follow. > > >> 1. I don't believe accessing 64k of the ZMI's VME address space is a >> valid operation, could this be causing the bus to hang? Actually, I >> have this doubt because I am unsure how exactly the master window is >> setup. >> > > Are you reading the whole of the 64k? From memory, the tsi148 has a minimum > window size of 64k, this should be fine as long as you don't read outside > the devices registers. > > >> 2. From the documentation of ZMI 4100, it is claimed that the board >> supports VME64 and VME64X. However, I am not sure if master.cycle >> bits for 2eVME need to be set or not?! >> > > If you want to use the high speed block transfer modes, set them as required > in the cycle properties. > > >> 3. Is there away to prevent the bus from hanging by modifying tsi148 >> device code? >> > > I'm not sure why it's hanging, I'm not familiar with the hardware which > doesn't help. Do you have a VME analyser to see what is actually happening > on the bus? > > >> Thanks for reading this far, and any help is sincerely appreciated! > > > Hope that helps, > > Martyn > > -- > 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/driverdev-devel
