Hi, lovely linux people, I just found that the printk called from insde the kernel and the printf from the busybox is ultimately using the same routine. (When we use printf from busybox, it eventually calls the system call sys_write which eventually calls some time of bit blitting functions. The printk in the kernel also uses the same bit blitting functions. bit blitting functions writes pixel data line by line to draw the characters on the LCD)
For example, to hide the cursor, which happens both in printk and printf cases when a new data is written, in printk case : the hid_cursor(vc) is called from inside vt_console_print function. in printf case : the hid_cursor(vc) is called from inside do_con_write function. * vc is of type struct vc_data *. Since the hid_cursor function is the same, it follows the same path after that. To name the main functions in this case .. From the hid_cursor, vc->vc_sw->con_cursor(vc, CM_ERASE) is called which is fbcon_cursor function. Then fbcon_cursor calls ops->cursor(vc, info, mode, y, get_color(vc, info, c, 1), get_color(vc, info, c, 0)) which is bit_cursor. Then bit_cursor calls soft_cursor(info, &cursor). Then soft_cursor calls info->fbops->fb_imageblit(info, image) which is cfb_bitblit function. Then cfb_bitblit calls fast_imageblit(image, p, dst1, fgcolor, bgcolor). Then finally fast_imageblit repeatedly calls FB_WRITEL((end_mask & eorx)^bgx, dst++) which is actually writing the pixcel data (combined pixels in 32 bits) to the framebuffer memory. My problem is : the same function path works for printk (texts are written on the LCD ok), but the same function path doesn't work for the printf case. It just stops at the first pixel data write (FB_WRITE) in printf case. I guess the ack is not coming from that memory. I've printed the address of the frame buffer and it looked not much different (0x69xxxxxx). I'll check if the address range is really in the frame buffer range allocated before (during the framebuffer probe initialization). I'll also look into the MMU page table setup.. But I thought there maybe someone who has had the same experience like the one I have now. Has anybody have similar situation before? (printk prints ok but printf doesn't print to the LCD using frame buffer) Any hint would be appreciated. Thank you! Chan ________________________________ From : "Chan Kim" <[email protected]> Sent : 2014-03-17 09:14:08 ( +09:00 ) To : [email protected] <[email protected]> Cc : Subject : RE: Please help.. trying to use USB keyboard to open a shell on LCD display There is no reponse yet to this question.. any help/hint would be appreciated. I found that I may have to use getty in the /etc/inittab file to get tty for a vc. For busybox, the example in init/init.c suggests entries like tty4::respawn:/sbin/getty 38400 tty4 I earlier found the keyboard seems to be connected to tty1 and the printk output is switched to tty1 towards the end during the initialization. So I tried in the inittab tty1::respawn:/sbin/getty 38400 tty1 and 1::respawn:/sbin/getty 38400 tty1 But didn't work. I know how to start a shell on tty1 (using inittab). But How do I map tty1 to the vc and to the LCD using boot argument or busybox setting? This seems to be the key question. Thansk, Chan ________________________________ From : "Kim Chan" <[email protected]> Sent : 2014-03-12 15:31:17 ( +09:00 ) To : [email protected] <[email protected]> Cc : Subject : Please help.. trying to use USB keyboard to open a shell on LCD display Hello, folks, It is a comfort to me that I have people to ask questions here and I hope I could be answering to some hard quetions someday. I've beeing trying to attach a USB keyboard to our embedded system to open a shell on the LCD display using framebuffer console. The USB host controller is from the opencore(USB1.1) and it works for USB memory. Some of the boot arguments are (I've tried some variants) "console=tty1 " "fbcon=map:0000,font:SUN8x16,vc:1-3 " "root=/dev/ram " The problem is, after the final sys_execve() which executes /sbin/init of the ramdisk, I cannot see any printf results frome the busybox init_main function not to mention the shell. So I cannot use shell commands like getty. Using uart as the console I can see printf results in the busybox init_main routine. (I use "console=ttyS,mmio,0xff003000,115200n8 " in that case) Using some prints on separate uart print routine, I can see from the kbd_event function that the key value is going to current vc which is using tty1. The key value is then handed to put_queue function where the character is somehow copied to tty buffer. Flush_to_ldisc is scheduled for it and it will probably get passed on to the virtual console. By the way, I guess the keyboard data is delivered to current fg_console (vc 0 which is using tty1). Added to this, there is a notifier_call_chain and the notifier block is registered by vcs_poll_data_get function which I don't know weather is necessary or not. So one of my questions is if vcs is necessary for my case. (I guess not. There is no other notifier blocks registered) I gathered that without inittab (I don't use inittab which should be ok for most cases) the assumed default inittab tty2::askfirst:-/bin/sh tty3::askfirst:-/bin/sh tty4::askfirst:-/bin/sh is being applied by the busybox so there maybe 3 shells on tty2,tty3, and tty4 running somewhere. But even if there are shells running I don't know how to switch to those ttys. I tried using Ctrl-Alt F2 (or F3, F4) using the USB keyboard to switch to tty2,3,4 to see if any shell comes up on the LCD but couldn't see it. I tried using inittab with no avail before. And I don't know how the printf in busybox is connected to the kernel. I guess busybox talks with stdio(stdout,stdin..) and the file is connected to the kernel anyhow. I've digged up how vc driver is connected to the console switch functions and to the bit blitting functions and how the printk is handled in the kernel. But these console, tty, framebuffer console.. things are very complex to me. and I hope somebody could point me to what should be checked. Any hint will be deeply appreciated. Best Regards, Chan _______________________________________________ Kernelnewbies mailing list [email protected]<mailto:[email protected]> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
