Re: More bugs in vme

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25/02/13 10:44, ternaryd wrote:
> On Mon, 25 Feb 2013 10:22:28 +0000
> Martyn Welch <martyn.welch@xxxxxx> wrote:
> 
>>> I haven't been able to get the serial console working. This is
>>> U-Boot based, and the last line is: "console [tty0] enabled,
>>> bootconsole disabled". Then I use ssh to log in. But after the
>>> freeze, this is no longer possible. 
> 
>> Do you have a valid console statement in your bootargs?
> 
> I've got this: "console=/dev/ttyS0,115200", but I also tried without
> "/dev/".
> 

IIRC, you don't need the "/dev/", but you may need something like "n8" on the end:

"console=ttyS0,115200n8"

>> Do you have a getty set up on your serial port in inittab (or
>> wherever it's set on a systemd based system)?
> 
>         T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
> 

That looks right based on the man page on my system, that said a lot of (quite
old) the NFS roots I have lying around on my system seem to have the baud and
port round the other way. It might depend on which getty you have.

>>> - With my version of vme_user.c, I can perform a write using an
>>>   ioctl call which yields vme_master_write(), or by lseek and
>>>   write() calls. The freeze happens anyway, but with lseek() I
>>>   say that a given offset of 8 will show up as 135168.
> 
>> Um, I think this may be your problem.
> 
> I thought so. For this reason, I added an ioctl call for writing 16
> bits at a given address, using vme_master_write(). There is no lseek
> anymore, but it freezes nevertheless.
> 

Have you got a VME analyser? I'd check to see what address is being accessed
on the bus.

Have you tried to read from anything?

>> For A16 master windows on the tsi148, the only valid vme_addr is 0x0.
> 
> As I said, I'm very sure, this is not the case, because on the same
> board, booting OS-9, the test program works.
> 

I'm looking at the datasheet, I'm fairly sure that I'm right.

>> The registers are probably set with the base address at 0x0 and so
>> you probably aren't reading and writing where you expect to be
>> reading and writing.
> 
> This is what I imagine is causing the lock-ups. Is there an easy way to
> allow for different base addresses, beside skipping the check_window
> test?
> 

It's a hardware limitation for A16 master windows.

>>> - I always thought that the card in slot 1 is the arbiter and, by
>>>   default, the bus master, until some other card is assigned bus
>>>   master. I would like to be sure, but I couldn't find any function
>>>   could inquire.
> 
>> It's automatic in terms of bus accesses.
> 
> Does this mean, the local controller will become automatically bus
> master as soon as the application tries to write to a master window?
> 

I believe so.

>>> -The cards allow to adjust a dip switch to select automatic or
>>>  manual geographic addressing, but in both cases, slot 0 is
>>> returned.
> 
>> Which cards?
> 
> MicroSys VME1022. At one point, I inserted two of them into the create
> in slot 1 and 2, using different NFS root file systems, but the same
> kernel image.
> 

Do you have a slave card you can try reading from (something that is known
"good")?

>> Are you sure the geographic address lines are wire back to the VME
>> bridge chip correctly (I know of boards where they aren't, sometimes
>> the bus address is exposed via other custom route...).
> 
> No, I am not sure.
> 
>> That looks like it's not detecting the geographical addressing.
> 
> Does this mean, I would have to add the kernel boot option
> "vme_tsi148.geoid=1" and "geoid=2"? And while at it, should I add
> "vme_tsi148.err_chk=1" in order to get bus errors rather than lock-ups?
> 

If it's not wired correctly and you want geographical addressing, yes.

The error checking may help you see what's going wrong.

Martyn

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


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux