Bug in vme subsystem (vme.c)

[Martyn Welch]

On 25/02/13 18:09, ternaryd wrote:
> On Mon, 25 Feb 2013 15:01:40 +0000
> Martyn Welch <martyn.welch at ge.com> 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.
> 

"there can be only one full sized *slave* window for each address space"
(and no other windows if that's the case, however A16 is the only
address space you'll probably be able to do that in without blowing your
PCI map...)

>> "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
> 

Because it's purely a translation between the two. PCI + offset = VME
address. The limitation is also on the offset registers (I can't
remember the offical name of the top of my head).

>> 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.
> 
 Yes :-)

Martyn