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?
>> 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
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?
In tsi148_master_set(), restriction is tighter, but I could live with
them as well:
(vme_base & 0xFFFF)
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. As a matter of fact, removing the check_window call
in vme.c, my address was accepted. 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.
> 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).
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 believe that the size shoudlbe 10000 rather than ffff, but it does
work like this. 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. 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,
--
Christoph
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
