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
