On 25/02/13 13:50, ternaryd wrote:
> On Mon, 25 Feb 2013 12:10:28 +0000
> Martyn Welch <martyn.welch@xxxxxx> wrote:
>
>>> On 25/02/13 10:24, ternaryd wrote:
>>> But I believe, that even the first test is incorrect. If vme_base +
>>> size must not be larger than VME_A16_MAX, and if size is the full
>>> size (which is VME_A16_MAX), than 0x0 is the only value for base.
>
>>>> Can't check that in vme.c, the restriction you mention is hardware
>>>> dependent.
>
>> It might be for the tsi148, but it isn't for the Universe II and
>> might not be for other VME bridges.
>
> Not being able to have more than one a16 window on the VMEbus seems to
> me a rather severe restriction. Is it unavoidable to share this with
> older bridges?
>
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.
>>> In the case of the tsi148, see tsi148_slave_set() in
>>> drivers/vme/bridges/vme_tsi148.c. The Universe II has different
>>> restrictions.
>
> granularity = 0x10;
> (vme_base_low & (granularity - 1)) == 0
>
That's in tsi148_slave_set(), the granularity of the slave window depends on
which window is being used. The tsi148_master_set() function has:
/* Verify input data */
if (vme_base & 0xFFFF) {
dev_err(tsi148_bridge->parent, "Invalid VME Window "
"alignment\n");
retval = -EINVAL;
goto err_window;
}
> so vme_base_low should be a multiple of number 16. I can not see any
> other restriction. Am I looking at the wrong place?
>
Yes, you are reading the verification for the slave window, not the master window.
> In tsi148_master_set(), restriction is tighter, but I could live with
> them as well:
>
> (vme_base & 0xFFFF)
>
Nope - one, it's a 16-bit address space.
> This still allows for 65000 different base addresses. And it is OK with
> vme_base = 0xffff0000. I can't see the restriction vme_base <=
> VME_A16_MAX here.
It's already been checked in vme.c as that's a test that can be done generically.
> As a matter of fact, removing the check_window call
> in vme.c, my address was accepted.
But it can't be honoured by the hardware.
> The configuration of the master
> window did not generate any visible error or misbehavior. I also
> performed a GET for this master window, and the address was still
> there, although all of the sudden some additional bits where set (I
> believe regarding 2eSST or something similar). But this shouldn't cause
> a lock-up. It might cause the transfer to fail, because the I/O card is
> older than 2eSST (or even VME64), but a freeze is not to be expected.
>
Unless you've just told the hardware to do something it can't do and which it
hasn't been designed to gracefully deal with.
>> Table 60 on page 239 shows bits 15:0 for Outbound ("master" in driver/
>> Universe II parlance) windows as reserved.
>
> I don't have the Universe II manual (at least none with 239 pages), but
> I do have two versions of the Tsi148. I could neither find the base
> address register for "master window" nor "outbound window" (but outbound
> translation, which by context obviously refers to PCI/X..VME).
>
"Outbound Translation Starting Address Lower (0-7) Registers"
The driver does the translation to PCI/X addresses.
> The reason, why I do think 0xffff0000 is a valid VME base address on
> tsi148 for address space A16 is the OS-9 configuration. It requires a
> setup in the U-Boot, which is:
>
> tsi148 init
> tsi148 pci 90000000 ffff0000 0000ffff 01 02
>
I suspect that the upper bits aren't used by the hardware. The u-boot driver
is doing no sanity checks.
> I believe that the size shoudlbe 10000 rather than ffff, but it does
> work like this.
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.
> I changed 01 to 19 as I was told to use supervisory
> mode. Then OS-9 starts and a test application is executed. That opens a
> data module (OS-9 jargon for shared memory) which is set to
> 0x9000-0000, the given PCI address. Then, two bytes at offset 8 and 9
> are written in certain intervals, and a test module shows with LEDs
> that the values have been read. (The issue about D8 odd/even is still
> in my question queue, but I could live with D16, I guess). One curious
> thing is a SYNC macro, which consists of
>
> asm ("eieio ; sync ; isync");
>
> On the net I could find, that these are sort of a barrier (on different
> levels), forcing the CPU to execute all queued commands, thus ensuring
> the order of them. It seems to be a particularity of the PowerPC. I did
> sprinkle those barriers in vme_tsi148.c, but no change.
>
> I tried to do this with the U-Boot, but couldn't figure out the CPU
> memory where PCI address 0x9000-0000 is mapped to (using 90000000 does
> manage to freeze the board). I also tried to do this in Linux with mmap
> FIXED, but it didn't work (probably because I did something wrong, but
> I don't know what).
>
> In the end, I find it hard to believe, that they wouldn't allow more
> than one 64k block of VME addresses to be used as A16.
2^16 = 65536
> As ffff0000 seems
> to be hardwired in the I/O module, I also don't have a lot of choices.
> And the board still freezes. Here are 5 of those boards, and I use them
> round robin, in case one is defect. I won't have broken all, right?
>
> Thanks,
>
--
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/devel
