On Mon, 25 Feb 2013 15:01:40 +0000 Martyn Welch <martyn.welch@xxxxxx> wrote: Once again, you are right on all accounts. There was a dip switch which wasn't moved properly all the way, causing this bad misbehavior. Now, vme_tsi148 0001:08:0e.0: Board is the VME system controller vme_tsi148 0001:08:0e.0: VME geographical address is set to 1 vme_tsi148 0001:08:0e.0: VME Write and flush and error check is enabled vme_tsi148 0001:08:0e.0: Setting CR/CSR offset vme_tsi148 0001:08:0e.0: CR/CSR Offset: 1 vme_tsi148 0001:08:0e.0: CR/CSR already enabled it is the system controller. I'm not sure, if the geo addr is found correctly, because this is still given in the kernel command line. The last line is strange, but doesn't seem to be hurting. > That check doesn't restrict it at all. That's a sanity check. You > can't have a window at a specific offset bigger than the address > space can hold. OK. Slave windows must not overlap, and there can be only one full sized window for each address space. Got it. My mistake was to think, that the bit width of the addresses wouldn't apply to the base address. > "Outbound Translation Starting Address Lower (0-7) Registers" > > The driver does the translation to PCI/X addresses. Can't follow you here. Why is an PCI/X address limiting to addresses in the VME address spaces? >> tsi148 pci 90000000 ffff0000 0000ffff 01 02 > The hardware needs the start and end address. Looking at the u-boot > driver here: > https://github.com/lentinj/u-boot/blob/master/common/cmd_tsi148.c > > ffff appears to be right. Something worth to note, unless we happily use Linux, because "size" then is just the wrong word. >> As ffff0000 seems >> to be hardwired in the I/O module You were also right at this point. I can actually write 0 instead of ffff0000 and it works just the same. Thanks a lot, -- Christoph _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
