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/".
> 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
>> - 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.
> 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.
> 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?
>> - 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?
>> -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.
> 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?
--
Christoph
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
