Bug in vme subsystem (vme.c)

ternaryd ternaryd at gmail.com
Mon Feb 25 18:09:23 UTC 2013


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.

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



More information about the devel mailing list