Hi Martyn, Thanks a lot for your guidance. I am back working on vme and I am trying it with a newer kernel, and I seem to have gone backwards! I upgraded to linux kernel 3.14.9 (on Fedora). Re-compiled the kernel with the vme support etc. I now get the below in my log, and don't see any vme related files in /dev !! [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.9 root=UUID=aee6e594-4be8-46d4-abe6-7c054ef239b0 ro vconsole.font=latarcyrheb-sun16 vme_user.bus=0vme_tsi148.err_chk=1 rhgb quiet [ 1.879625] vme_user: VME User Space Access Driver [ 1.879846] vme_tsi148 0000:04:04.0: Board is the VME system controller [ 1.879849] vme_tsi148 0000:04:04.0: VME geographical address is 0 [ 1.879851] vme_tsi148 0000:04:04.0: VME Write and flush and error check is enabled [ 1.880240] vme_tsi148 0000:04:04.0: CR/CSR Offset: 0 [ 1.880244] vme_tsi148 0000:04:04.0: Enabling CR/CSR space Any help is sincerely appreciated :) Cheers! On Tue, Jun 24, 2014 at 4:19 AM, Martyn Welch <martyn.welch@xxxxxx> wrote: > On 23/06/14 16:05, Maurice Moss wrote: >> >> 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? >> > > That's probably quite old now. Depending on your hardware there may be > important fixes. There was certainly one to get the driver working on SBCs > with IOMMUs, though I'm afraid I don't know exactly which version that > landed in off the top of my head. > > >> 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? >> > > Do you have a second SBC? It would probably be easier to prove out basic > accesses between 2 SBCs. > > >> 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? >> > > Might be worth checking that the backplane supports geographical addressing. > Can you put the SBC in the slot that the slave is usually in? > > Assuming that the SBC is wired to support geographical addressing (and they > aren't always), the driver will print out the slot it detects it's in when > the driver is loaded. Make sure your not forcing the geographical address > via the kernel param! That'll hopefully confirm that the slots getting the > expected address. > > >>> 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 >> > > That sounds right. > > Martyn > >> 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 >> > > -- > 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
