From: James S. <jsi...@tr...> - 2001-08-26 16:23:51
|
> No, no luck, ... > > it dies with : > > unable to handle NULL pointer dereference at virtual address 0000000c > > eip is c01e60a1 (__fb_try_mode is c01e6020, next is fb_set_var at c01e60d0). > > call trace seems to be : > > pm3fb_mode_setup > > pm3fb_real_setup > > init > > kernel_thread (not sure about this one, i missed one digit and had to guess > it.) > > I start the kernel with grub and : > > title linux (2.4.7-ruby pm3fb) > root (hd0,0) > kernel (hd0,0)/boot/vmlinuz-2.4.7-ruby root=/dev/hda1 > video=pm3fb:mode:0:800x600-75,mode:1:640x400-60,off > > Hope this is helpfull and i did not mess up some stuff. > > Note, i got ruby from cvs yesterday, and simply copied the linux directory > over to a fresh 2.4.7 tree.? Hm, strange. Lets see. I see what is causing alot of the problems. In the new fbdev api you have to do the reverse of how you defined your data. You have: struct pm3fb_info { struct fb_info gen; unsigned long board_num; /* internal board number */ unsigned long use_current; struct pm3fb_par *current_par; struct pci_dev *dev; /* PCI device */ unsigned long board_type; /* index in the cardbase */ unsigned char *fb_base; /* framebuffer memory base */ u32 fb_size; /* framebuffer memory size */ unsigned char *p_fb; /* physical address of frame buffer */ unsigned char *v_fb; /* virtual add ... The upper fbcon layers only can deal with struct fb_info itself. This is one of the big reasons why the fbcon layer shrunk so much in size for ruby. You can blindly pass around hardware data without ever touching it in the upper layers. What you need is: struct fb_info pm3fb_info. struct pm3_par { .... /* Anything hardware specific and we can't shove into struct * fb_info */ .... } xxxfb_init() { /* fill in par values */ par->fjfjfjf = hjfhfhf; .... pm2fb_info.par = par; } Will this driver work on a pm2 card? I recently came into possesion of one. |