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
