> > > > On Mon, Jun 22, 2009 at 13:16:55, Young, Joseph wrote: > > > > > >> I am porting the Davinci Linux kernel to a new and similar TI > > > > > >> device, called Jacinto2. I am at the point where the init > > > > > >> program passed to the kernel by the bootloader is initialized. > > > > > >> The problem that I am experiencing is that, whichever init > > > > > >> program I pass, it can display text, but it cannot receive > > > > > >> characters from the keyboard. > > > > > >> > > > > > >> I know the serial interface is ok, because I inserted > > > > > >> prinktk's and it both issues a serial interrupt when I press > > > > > >> any key, as well as retrieves the correct character from the UART > > > > > >> buffer. > > > > > >> However, the characters I type do not show up in the shell, and it > > > > > >> doesn't seem to react to keyboard signals. > > > > > >> > > > > > >> When one passes /bin/sh as the init program, it will display the > > > > > >> '# /' > > > > > >> of the shell prompt, but the keyboard has no effect. When I > > > > > >> wrote a simple 'hello world' program to print text, receive > > > > > >> text from the user, and then print another line, it will print but > > > > > >> not receive the keystrokes. > > > > > >> > > > > > >> Passing /bin/ls (which redirects to busybox) will display my > > > > > >> file system as I expect, so I don't think that my busybox is > > > > > >> broken. > > > > > >> > > > > > >> Is anyone familiar with how this is initialized when the kernel is > > > > > >> booting? > > > > > >> Does anyone have a clue what I could be missing so that the > > > > > >> serial interface would record keystrokes but not pass it to the > > > > > >> tty interface or shell? > > > > > > > > > > > > Not sure about the details of Jacinto2, but on the other SoCs > > > > > > in the family, the UART TX and RX signals are > commonly mux'd with > > > > > > other pins. > > > > > > > > > > This is correct, the UART0 TX,RX, RTS, and CTS are muxed with some > > > > > GPIO pins. > > > > > > > > > > > Have you confirmed that all the UART signals are mux'd correctly? > > > > > > > > > > Yes, because the characters I type are appearing in the serial > > > > > buffer on the device (I am printing out the characters received > > > > > with printk's) but they are not having an impact on the console. > > > > > > > > > > > > > I would like to guess there is something wrong with your kernel > > > > configuration. Can you start from davinci_all_defconfig and then > > > > modify only the parts absolutely required (like enabling > > > > ARCH_DAVINCI_JACINTO2 (??)). > > > > > > Hmm. I tried this, using only the ARCH_JACINTO2 options, and it > > > performed the same way. I think it's a problem with the tty layer > > > passing the data to the shell. I don't think it's the serial layer > > > because when I press a key, the serial interrupt kicks in, and if I > > > add a printk to the uart_insert_char function in > > > /include/linux/serial_core.h, I can print out the serial buffer, and > > > it has the characters I type. I think somewhere the tty_driver or > > > tty_buffer isn't getting initialized properly. > > > > > > How does the tty layer pass characters to user-space processes? > > > > > > > Also, within TI we are using filesystem from Arago project for testing > > > > http://arago-project.org/files/releases/. > > > > > > Thanks! As soon as I can boot my RAMDISK fs, I'll start testing with > > > Arago :) > > > > I meant to ask you to use the pre-built ramdisk image available from Arago > > to eliminate any issues with the filesystem > > you may be using. > > > > Well, I tried the Arago FS, and it still doesn't receive keyboard input. > However, it provided me with additional input: > ---------------------------- > RAMDISK: gzip image found at block 0 > EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended > VFS: Mounted root (ext2 filesystem) on device 1:0. > Freeing init memory: 148K > uart_open(0) called > ttyS0 - using backup timer > *** run_init_process(/bin/sh) > /bin/sh: can't access tty; job control turned off / # > --------------------------- > > It says it can't access the tty. Is this normal when booting with a serial > console through ttyS0? >
So, as it turns out, the TTY and serial layers were fine. The actual problem I'm having is with the schedule_delayed_work call. The function tty_flip_buffer_push in drivers/char/tty_buffer.c calls flush_to_ldisc, which pushes the data to user space, if the tty->low_latency flag is set. Otherwise, it will push onto the scheduler with schedule_delayed_work. The problem here is that this delayed work is never revisited. Thus, my character input was never sent through to user space because the scheduler never called the process to do it again. For the time being, I have hard coded it to always call flush_to_ldisc instead of the schedule_delayed_work, but this is not a fix, this is a workaround. Does anyone have any suggestions as to why this scheduling call wouldn't behave correctly? Thanks, Joe_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
